Hi Tal,
I remember we had the conversion of substitution mapping sometime ago, where we
agreed upon of looking at available service-models(service-templates) when we
dont find a satisfiable capability within our service. I just want to make sure
if we are on the same page as the implementation work is started for this. Also
I have few questions with respect to the points you had put forth. Please find
my comments in-line against each of your points.
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.
[DJ] - When you say option is there to look for another instantiated
service is this an available option with current ARIA ?
- When you say instantiated service, is it the service or the
real world service ?
- I think the 3rd point of yours is related to this service
level mapping. When you say a special node would be added to the current
service, will that node be unique across service A and service B(instantiated
service) ? Will a life-cycle operation would be called for that node which is
added to service A as part of the workflow execution ?
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.
[DJ] - Just to understand more on this, Let us assume we have
service-template A and service-template B. Am trying to create a service A from
service-template A. One of the node is abstract and this capability is provided
by node from service-template B.
- Now I assume service A will have node contributed by
service-template B and also its nodes. Will this approach I don't see a need
for multiple workflows.
- Or is it like service B would also be created automatically.
In that case how would the workflow be called for service B ?
- As you stated we have this challenge with multiple
service-template providing the same capabilities on which one to use.
- Finally am not getting the exact meaning of the last
statement of yours "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". I assume you are talking having a provision
where the user can mention the service-template to be used
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.
Regards,
DJ
-----Original Message-----
From: Avia Efrat [mailto:a...@cloudify.co]
Sent: Wednesday, August 09, 2017 6:28 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Service Composition / Substitution Mapping
Currently, the support for substitution mapping is extremely limited. the
substitution_mapping section is parsed and validated, but nothing more.
However, supporting this feature (and hence, allowing for service
composition) is of high priority. Currently, we are at the the designing phase
- going over the spec to identify vague and ambiguous parts, and consolidating
TOSCA's pov regarding substitution mapping with the current ARIA implementation.
Relevant Jira issue:
https://issues.apache.org/jira/browse/ARIA-292
On Tue, Aug 8, 2017 at 11:03 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:
> 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!
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
