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.