Thanks Matej, I think weâre on the same page. To summarize:
Â
Letâs just focus on import statements for now (artifacts can be treated the same way). We need to consider two different scenarios:
1.
A scenario where an import statement refers to a file within the same CSAR (or repository) as the file that contains the import statement
2.
A scenario where in import statement refers to a file in a different repository as the file that contains the import statement
Â
Letâs first discuss the second case (where an import statement refers to a file in a different repository). This can be handled in one of two ways:
1.
The import statement specifies both the (external) repository as well as a file name relative to the root of that repository
2.
Or, the import statement specifies a fully-qualified URL, which eliminates the need to specify a repository
Hopefully this shows that specifying both an external repository as well as a fully-qualified URL in the same import statement should be invalid.
Â
In the first case (specifying a file within the same repository) is a special case of number one above (specifying both the repo and a file name relative to that repo): by omitting the repo name, weâre assuming weâre using the
repo weâre already in. The âfileâ component in such an import statement then specifies a path relative to the root of the (local) repository, and as a result must not include a URI scheme (or authority).
Hopefully these different cases make it clear that it is invalid to use fully-qualified URIs to reference files that are relative to the root of some repository, independent of whether
the âlocalâ repository or some external repository is being used.
As for the syntax for the path that specifies a file name relative to the root of the component, I fully support Talâs suggesting that we should base this on the syntax for the path
element of the URI syntax.
If this makes sense to everyone, we should update the spec to clarify this (and include examples).
Thanks,
Chris
From: Matej ArtaÄ [mailto:matej.artac@xlab.si]
Sent: Monday, October 21, 2019 1:09 AM
To: 'Tal Liron' <tliron@redhat.com>; Chris Lauwers <lauwers@ubicity.com>
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] relative vs. absolute path names in import statements
Hello Chris, Tal,
I have checked now: we actually do the same, we treat absolute paths as being rooted in the CSAR root folder. So path /etc/passwd always points to /path/to/the/current/csar/etc/passwd.
So even though my intuitive interpretation was that
file:///etc/passwd points to a file on the orchestratorâs local machine, the safe and correct interpretation is the path relative to CSAR.
As for the general URLs, I agree that they are useful and probably make sense. However, our path currently is for the orchestrator to expect that all the imports
and artifacts are available locally in the CSAR. If in the future, the use cases will call for it, weâll also add support for general URLs, but then the orchestrator will have a pre-run step to gather everything and rewrite the URLs to local paths.
One of the reasons for this decision is that in the past while using Cloudify, deployments would fail because the external resources would sometimes not be available
â GitHub was down, or we would hit a limit on the download count of some .tar.gz that would be crucial for installing software, things like that.
Best regards,
Matej
|
|
|
Matej ArtaÄ, Ph.D. / Project Manager |
|
Project Manager, Platform and Systems Orchestration Member of OASIS TOSCA Standard Technical Committee Member of
steampunk.si |
From:
tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
On Behalf Of Tal Liron
Sent: Sunday, October 20, 2019 7:27 AM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] relative vs. absolute path names in import statements
On Sat, Oct 19, 2019 at 6:10 PM Chris Lauwers <lauwers@ubicity.com> wrote:
That could work, but it doesnât really convey the idea that all referenced files must be contained within the repository. For example, if I say;
that would cause casual readers to believe that weâre looking for the /etc/passwd file on the local machine, rather than for an /etc/passwd file within the local CSAR or local repository. I think such an approach would be very confusing.
Relative file URLs do not require a host. This would be enough:
file:etc/passwd
That would (possibly) interpreted as relative to the CSAR root. But really you don't need a URL scheme, as it can inherit from the source document. So this should be enough (and it's also a valid relative URL):
etc/passwd
Is identical to "file:etc/passwd" if the importing document is local. Absolute paths are more difficult to interpret, as Matej implied. Relative
to what machine? So something like this:
Might mean ... the local machine where you run the parser? The orchestrator? The remote server? This could be left up to implementations to figure out. And they may very well disable absolute "file:" URLs for security and
practical reasons. Any good URL library will be able to tell you if a URL is absolute or not.
I'll also point out the "http:" scheme URLs are very useful, both for imports and for artifacts. E.g.:
imports:
It could be very useful (and indeed ONAP does this, as does Cloudify) to import from a well-known DNS hostname within the orchested environment. I don't see any reason not to use URLs, as they are flexible enough (they were
designed exactly for such use cases). But in case there's strong resistance, I don't see why TOSCA has to have an opinion about their interpretation. I'd rather have it left vague than have a limiting opinion. (Unless ... we really want to talk about the CSAR
spec, which is woefully skimpy right now.)
Using the URL scheme of the current document is obvious, I think, for relative URLs. And very useful. For example, if the "sdn.yaml" above in
turn imports a file named "plugins/opencontrail.yaml" then it would be interpreted as relative to "
http://cluster-inventoy.org/tosca/profiles/", so it would be "
http://cluster-inventoy.org/tosca/profiles/plugins/opencontrail.yaml". This is a common and useful
pattern.
By the way, Puccini (which expects URLs) handles the "implicit" import of the Simple Profile by using a custom URL scheme, "internal:", for
resources embedded inside the tool executable. Users don't see it, but could potentially do an import of an "internal:" URL path explicitly. Obviously, that's just a Puccini feature,
but still valid within the URL spec. My point: the URL spec is flexible enough for all our needs, in my opinion.