Hi I have looked at the data you have provided. I am trying to catch up (understand) to current ARIA support for substitution mapping. What is supported today and what are the limitations/considerations? What is missing (hence the need for full implementation)? Do you have an working example or set of guidelines for using substitution mapping today? Or should I avoid it completely for now?
- Steve B -----Original Message----- From: Tal Liron [mailto:t...@cloudify.co] Sent: Monday, August 07, 2017 8:41 PM To: dev@ariatosca.incubator.apache.org Subject: Re: Service Composition / Substitution Mapping Well, this is exactly what policies are for. :) Again, I think the rule of thumb should be that users put policies in place *only* if the defaults do not suffice. On Mon, Aug 7, 2017 at 6:42 PM, Ran Ziv <r...@cloudify.co> wrote: > The sensible defaults Tal's mentioned sound indeed sensible to me. > I'd also like users to have control over this, though I'm a bit > worried about us getting too carried away with how arbitrarily we use > policies for configuring, well, pretty much anything. It might not be > a problem right now but I'm not certain that will remain the case in > the future when the number of them grows.. > > > On Wed, Aug 2, 2017 at 7:14 PM, Tal Liron <t...@cloudify.co> wrote: > > > 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! > > > > > > > > > > > > > > > > > > > > > > > > > > > >
