To my eyes, the spec doesn't speak of runtime service substituion, but
parsetime template composition. IOW, substitution mapping is a fancy
"include", or the equivalent of an interface definition. Is it understood
by the ARIA team that this includes proxying of running services? IOW, if
my template requires a database service that my template does *not* want to
control the lifecycle of, I can "substitution map" an instance of a
template (i.e. a running service)? This would be a lovely feature, but
it's not really a "substitution map", rather more of a "service proxy" (as
implemented as a plugin in Cloudify). Just trying to clarify. Maybe the
community thinks that "substitution map" as something that occurs beyond
parsetime, or should.
On Fri, Aug 11, 2017 at 9:52 AM, Tal Liron <t...@cloudify.co> wrote:
> 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
> > 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
> > 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.