ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From D Jayachandran <>
Subject RE: Service Composition / Substitution Mapping
Date Fri, 11 Aug 2017 08:23:27 GMT
Hi Tal,

Thanks for the explanation.

So we have 2 options when the reqs-caps are not met within the same service-template

Option 1:
	To look at satisfying nodes present in a substituting service, Have these nodes part of the
newly created service and remove the substituting service(nodes with different ID's. Also
we are very much in favor of 	UUID )
	With this approach I guess the substituting service should not have any associated workflows
running. If at all an workflow execution is already triggered I hope this service will not
be considered for substitution.
	I hope this is the correct approach when we are looking at a service for the substitution

Option 2:
	While creating a service look at the req-caps at the service-template level and create a
service including the nodes provided by the substituting service-template. With this approach
there would not be any 	service created from the service-template which is providing the substitution
functionality. The service-template would remain the same but only the service would be added
with extra nodes.

Are you considering both option 1 & 2 for the implementation ? If not which one do you
feel which take priority. I see option 2 at this stage could be the best possible approach
Also could you please let me know a tentative time for this feature to be available?

-----Original Message-----
From: Tal Liron [] 
Sent: Thursday, August 10, 2017 10:09 PM
Subject: Re: Service Composition / Substitution Mapping

Thanks for the feedback, DJ. What I wrote was just ideas for now, we're still in the investigation
phase and haven't implemented anything yet.

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 ?

I don't think it's reasonable for ARIA to work with a "real world service"
if it hasn't been modeled yet in some way. I do have a dream of someday having such a tool:
take an existing cloud service and produce a basic TOSCA service *and* service template for
it. But for now I think it's reasonable to expect the user to at least model the whole "real
service as some kind of logical node.

The question you ask about lifecycle operations are the right ones. In my opinion, the new
"composed service" should be a service instance in every respect, so workflows would indeed
happen on all nodes, including the sub-services that were added. Otherwise, why do composition
at all? The whole point is to combine everything together.

An interesting question is what happens to nodes after that get "composed"
into another service. From what I say above, it means their service IDs should change, and
in fact the original service would disappear. (By the way, things like this are another reason
I prefer UUIDs for nodes rather than have them be sequential within the service: nodes should
be allowed to move around between services.)

The only way you would know that these added nodes came from a another service template is
by following their node_template_fk to their service_template_fk. Otherwise they are all in
the same service.

> 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

I was thinking out loud there, comparing the two options. Thinking more about it now, I think
it's fine to run a normal "install" workflow on the big composed service (as I said, it should
be treated as a regular service instance), so I see no problem with instantiating one big
service automatically for the user. No need for the user to instantiate the sub-service first.

HOWEVER, during instantiation the reqs-and-caps engine should be careful to consider each
sub-service a separate "zone" for satisfying capabilities.
You don't want a requirement in one service template grabbing a capability of a node in the
other. The service is composed, but the service templates are still separate.
View raw message