Our goal with adding new "conventions" to ARIA, such as policies, is to always make them optional. The idea is that a plain-vanilla TOSCA template would "just work" in ARIA via sensible defaults. The extra stuff is there if you know you are using ARIA and you want to make use of its features. (The opposite is true, too: we make sure that any additions are still pure TOSCA and would be parsed validly by other TOSCA parsers.)
On Wed, Aug 2, 2017 at 9:08 AM, DeWayne Filppi <dewa...@cloudify.co> wrote: > Cool. Missed that. That leaves things almost completely wide open from > the orchestrator side, IOW few predefined keys. Too few IMHO, but if > everyone uses ARIA conventions it could work. > > On Tue, Aug 1, 2017 at 11:49 PM, Tal Liron <t...@cloudify.co> wrote: > > > 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 <dewa...@cloudify.co> > > 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 <t...@cloudify.co> 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 <a...@cloudify.co> 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! > > > > > > > > > > > > > > >
