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?
Regards,
DJ
-----Original Message-----
From: Tal Liron [mailto:[email protected]]
Sent: Thursday, August 10, 2017 10:09 PM
To: [email protected]
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 world"
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.
