Well, DJ, it's all just opinion at this stage and feedback is welcome!

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

Yes, this is a good idea. It would be easy to discover this according to
the stored node state -- just make sure that all nodes are in a stable
state before composition.

This leads to a general issue: before composition, the substituting
services must be validated in some way before composition begins.

Also, let's all start using TOSCA terminology here: the containing service
is called the "top-level service," and the contained services are called
"substituting services."

Also, we keep using trivial examples, but it's definitely possible for a
top-level service to require several substituting services at the same
time. I can definitely see such things happening in NFV with even simple
service chains. Basically every VNF could be a substituting service.

So, actually one of the validations would be to make sure you do not create
circular composition: if the top-level also has substitution mappings, you
need to make sure that one of the substituting ones doesn't require it. :)
Not a very likely situation, but it would lead to failure.

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

I think both options 1 and 2 make sense and are useful, and actually one is
a subset of the other.

With option #2 (substituting a service template), it means new nodes are
instantiated and the composed service would include all nodes. So, an
"install" workflow would install everything at once. In this case we do
need to fix the lifecycle workflows to be "boundary aware," so that
workflows of substituting service nodes are part of their own task graph. I
think that possibly using a logical proxy node in between might solve this
situation automatically.

With option #1 (substituting a service) the substituting nodes might
already be installed. Or not (they might have been instantiated but still
not installed). So, the lifecycle workflows should only work on the nodes
that have not yet been installed.

The point is that we just need to beef up the lifecycle workflows to
properly work with boundaries and with a mix of nodes in different states.
If they can do that, then they can handle any kind of service composition,
whether it's option #1 or option #2.

I don't think we can provide a timeline yet, but I will say that we are in
the research phase and may have a POC soon. Avia is in charge of this JIRA,
so I will let him chime in with the current state of things.

Reply via email to