I agree! Luckily metadata exists in the 1.0 spec. :) http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/cos01/TOSCA-Simple-Profile-YAML-v1.0-cos01.html#_Toc379455044
On Tue, Aug 1, 2017 at 7:16 PM, DeWayne Filppi <[email protected]> wrote: > It occurs that it might be useful to be able to tag service templates with > arbitrary meta-data. Perhaps at one level carried forward from a CSAR > manifest, but also user definable. This would allow inter-service > references to be definitive, if desired. This could be implicitly defined > as a capability by the orchestrator, but some kind of special requirement > type(s) would be needed to utilize it. This way, external repos could be > used safely and directly without the separate load step. > > On Tue, Aug 1, 2017 at 12:43 PM, Tal Liron <[email protected]> wrote: > > > Thanks for the kudos. :) > > > > This topic was discussed on this list a while ago. It's indeed tricky to > > get right, because TOSCA leaves a lot of room for the orchestrator to > > implement. > > > > I'm thinking of it working something like this: > > > > 1. The reqs-and-caps engine by default will always look for satisfiable > > capabilities within the currently instantiated service. HOWEVER, if such > a > > capability is not present, the option is there to look for another > > instantiated service that exposes the capabilities in substitution > > mappings. > > > > 2. If we DON'T have another instantiated service, but DO have a service > > template that could fit the bill, perhaps we need to instantiate that > other > > service first. One obvious option is to do this automatically. But I feel > > like this can create unforeseen consequences -- for example, some dummy > > test template that someone happened to have in the database might get > > instantiated by mistake. Also, it might need to trigger multiple install > > workflows at once... a big mess. So I suggest that instead we provide a > > very detailed validation error here saying that the requirement cannot be > > satisfied, HOWEVER there exist service templates A, B, and C that can > > substitute for us, so maybe the nice user would like to instantiate them > > first? This seems very reasonable to me. > > > > 3. If indeed another service satisfies this, a special node is added to > the > > current service (with the correct type -- but without a service template > > foreign key), which serves as a proxy of the other service template. I'm > > not sure how we would mark this exactly. We can't use the service_fk > field, > > because it's still in our current service. So perhaps there's need of a > new > > fk field, maybe substituted_service_fk? > > > > The above might be "sensible defaults," but it seems to me that users > > really need control over this. So I propose to add a new aria.Composition > > policy that would let you provide hints for this mechanism. For example, > > you might want to "filter" the target service by service template name > and > > even by metadata in the service template. For example, you might want to > > require version 1.2.2 of a specific service, no less. > > > > Those are some quick thoughts. Exactly how such a policy would look with > > require more thought... > > > > > > On Tue, Aug 1, 2017 at 2:20 PM, Avia Efrat <[email protected]> wrote: > > > > > Hello all, > > > > > > I'm starting to work on a full implementation of substitution_mapping, > > > which will lead to the ability of service composition. > > > > > > For those unacquainted with substitution mapping, here are some quick > > > resources: > > > *From the spec > > > <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile- > > > YAML/v1.0/TOSCA-Simple-Profile-YAML-v1.0.html>, > > > sections:* > > > 2.10 > > > <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile- > > > YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#_Toc471725208>, > > > 2.11 > > > <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile- > > > YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#_Toc471725209> > > > (theory and examples) > > > 3.8.1, 3.8.2 (grammar) > > > *From Tal's amazing lecture on TOSCA > > > <https://www.youtube.com/watch?v=6xGmpi--7-A>:* > > > 00:00 until 12:30. > > > > > > If anyone wishes to: > > > * ask questions regarding this feature > > > * suggest real-life use cases > > > * offer their insight about vague parts of the spec > > > * anything else about substitution mapping and service composition > > > Then please, feel encouraged to leave your feedback! > > > > > >
