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?