RE: [tosca] Proposal for TOSCA repositories grammar

Hi Tal, as you know Iâm not in favor of associating semantics with properties (such as a ârepositoryâ property) but I would be interested in examples where repositories for artifacts can be provided at deployment time e.g. by allowing full URIs to be used as values for the ârepositoryâ keyword in artifacts, instead of (or in addition to) the name of a previously-defined artifact. That approach would be similar to how we handle operation implementations: you can specify the name of a previously-defined artifact, or you can have an inline âfileâ keyword that refers to the location of an artifact directly. Alternatively, we could keep the âurlâ keyword in repository definitions mandatory, but allow the value for the url keyword to be retrieved using get_input.

W.r.t. the second part of your proposal, do you believe support for âruntimeâ definition of which files need to be imported is a requirement (especially since in the majority of cases, we will import from the CSAR or from a profile, neither of which require the feature youâre suggesting).

Thanks,

Chris

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Tal Liron
Sent: Saturday, October 24, 2020 11:51 AM
To: tosca@lists.oasis-open.org
Subject: [tosca] Proposal for TOSCA repositories grammar

I've recently added robust repository management to Turandot, and it occurred to me that it's hard to fit it with the "repositories" keyword in TOSCA. Indeed, I ended up creating a base artifact type with its own "repository" property.

The issue is this: repositories in TOSCA currently need to be entirely defined at design time. If you use the optional "repository" keyword for an artifact, then that repository must be declared somewhere, and if it is declared then the "url" keyword there is mandatory. In short, currently you need to know the full URL of the repository in order to use it in TOSCA. However, what is more likely is that the URL depends on the runtime environment. It's good to have a well-declared repository for design purposes, but perhaps the "url" keyword should be optional, allowing the orchestrator to retrieve artifacts from the runtime environment. This is exactly what I do now with Turandot.

We get an interesting but different challenge with "imports". Here, again, we have an optional "repository" keyword with the same limitations. However, one difference is that imports absolutely need to be resolved during parsing. So, does that mean we can't make the "url" keyword non-mandatory? Not so fast! Remember that we now support a "profile" keyword for imports, which is explicitly delegated to the orchestrator to match the profile name. So why not allow the orchestrator an extra layer of delegation, to match the repository itself?

An example of how it would look:

repositories:

machines-staging:

description: VM images (staging)

machines-production:

description: VM images (production)

vendor:

description: Vender-managed repository (3rd party)

imports:

- url: types/acme.yaml

repository: vendor

namespace: acme

- profile: org.mycloud

namespace: mycloud

topology_template:

node_templates:

server:

type: mycloud:Server

artifacts:

image:

type: acme:Image

file: vm/centos.qcow2

repository: machines-production

So, as you can see there are no full URLs here and instead it is expected that the orchestrator will know how to reach these repositories. Is portability guaranteed? No. But this is the same challenge we have with our new profile support.

What do you think? Would this be a good direction for us to pursue? As I said, in my case, I had to work around this limitation in TOSCA by creating a special artifact type. But, should this be part of the TOSCA grammar?

tosca message