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
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
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.