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! > > > > > > > > > > > > > > > > > > > > >
