ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Baillargeon <steve.baillarg...@ericsson.com>
Subject RE: Service Composition / Substitution Mapping
Date Tue, 08 Aug 2017 20:03:47 GMT
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:tal@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 <ran@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 <tal@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 <dewayne@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 <tal@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 
> > > > <dewayne@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 <tal@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 
> > > > > > <avia@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!
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Mime
View raw message