Hi Tal, as you know Iâm not in favor of associating semantics with properties (such as a ârepositoryâ property)
I would also like this to be grammatical!
Â
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.
This situation is practically guaranteed in cloud-native environments in which the repository implementation would receive an ephemeral IP address. But, really, even in legacy clouds this could happen, say if your repository implementation is deployed on an OpenStack VM by the orchestrator itself.
One workaround could be to insist on a DNS solution, thus the repository URL could comprise of a known domain name that would indirectly reference the ephemeral repository IP address. But I think this would be a hefty requirement. Not all cloud platforms come with out-of-the-box DNS, and requiring DNS is non-trivial and complicated by the multiplicity of network domains (control-plane, data-plane, user-plane, etc.) on which these repositories might sit.
As an important example, let's look at Kubernetes. Kubernetes Service resources do get automatic in-cluster DNS registration, e.g. "my-repository.my-namespace.svc.cluster-domain.example". The problem is that in-cluster DNS is available for in-cluster workloads, not for the container runtime itself (e.g. CRI-O or Docker). So, the "image" keyword for a Pod resource will not be resolved by that in-cluster DNS, it would have to be available for the DNS used by the infrastructure data plane. For many deployments -- public clouds, for example -- that DNS implementation is non-writable.
For Turandot I solved this by a major refactoring that has made repositories first-class citizens, indeed they are managed by an operator as their own custom resource definitions. The repository is where artifacts are stored, substituted CSARs are stored, and also potentially TOSCA profiles can be stored there if they are CSAR-packaged (a feature we must address in the TOSCA ad hoc eventually: how to package a profile in CSAR?). The problem is that as the Turandot operator provisions (=schedules) these repositories, it won't be able to get an IP address for them until they are fully deployed. Thus, there's simply no way to specify the "url" for a TOSCA repository at design time, and I had to use a property as a workaround -- the property being the name of the repository, which Turandot then resolves from the actual Kubernetes resources.
Â
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).
We do have a solution for this via the new "profile" keyword for imports, which indeed delegates resolution to the orchestrator. But here's an interesting question: is it possible to specify both the "profile" keyword and the "repository" keyword for an import? Would it be possible to thus specify from which repository we want the profile to come? If it is possible, then the same delegation feature should be allowed for repositories, hence my proposal.
Alas, for artifacts do not have an equivalent in TOSCA. Everything right now must be made explicit. So my proposal is most important for artifacts. But hopefully my proposal will make sense for improving orchestration for both imports and artifacts.