ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tal Liron <...@cloudify.co>
Subject Re: Service Composition / Substitution Mapping
Date Tue, 01 Aug 2017 19:43:40 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message