ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ran Ziv <...@cloudify.co>
Subject Re: Service Composition / Substitution Mapping
Date Sun, 03 Sep 2017 09:06:23 GMT
I'm not sure I've followed why a policy would be necessary.

I too agree with the notion that picking a substituting service template
explicitly is against the spirit of this feature, for the reasons Avia has
explained.
If a specific template is needed, why not import it directly, or require a
more specific capability offered by the substituting service template?


On Thu, Aug 31, 2017 at 7:09 PM, Tal Liron <tal@cloudify.co> wrote:

> Regarding #1, I agree with Avia here. Substitution mapping is intended as
> an extension of requirements-matching-capabilities. As you know, a
> requirement can be as minimal as just specifying a capability type, but
> could optionally additionally specify a node and even include a node filter
> with more constraints. Unfortunately the substitution mapping grammar is
> still not very sophisticated in TOSCA 1.0, and while you can require a
> node, you can't specifically require it to be a substituted service
> template. That's why I'm thinking we may need to introduce a policy to fill
> in this gap for now. But indeed, if there is no such policy, available
> service templates could be tried arbitrarily one at a time until one
> satisfies the requirement (as Avia points out, this would require the
> composite service to be *entirely* successfully satisfied).
>
> On Thu, Aug 31, 2017 at 10:23 AM, Avia Efrat <avia@cloudify.co> wrote:
>
> > 1) Substitutable nodes (abstract nodes) are defined by their type. And a
> > node type should represent specific node/subsystem characteristics.
> Having
> > two node types ( with the same name) that represent different logical
> > entities seems odd, and indicates a possible bug in the design. That is
> > another reason why using so-called namespaces while creating type
> > hierarchies is a good practice.
> >
> > You could argue that if you have multiple sources for templates (e.g.
> your
> > own storage and a external catalog), there could be unexpected name
> > collisions of node types names. Having said that, we need to remember the
> > entire process of the substitution mapping.
> >
> > First, as you said, we are trying to locate a service template that has a
> > substitution mapping definition of the same type of the abstract node in
> > the top level template. But choosing the service template is only the
> first
> > step. The second step is instantiating the top level template along with
> > the substitution template. During the instantiation, requirements and
> > capabilities are matched. If not all requirements are satisfied
> > (considering both top level and substituting template), the substitution
> > mapping is not considered successful, and the instantiation fails.
> >
> > If that is the case, it makes sense to go ahead and try the next
> > substitution template that fits the type, and continue like so until we
> > find a substitution where all the requirements are satisfied during
> > instantiation.
> >
> > At this point you may be wondering, "what if the instantiation was
> > successful, but the source of the substitution template wasn't the one
> that
> > *I* wanted?". Well, You have to think about this issue in substitution
> > mapping terms. that is, when you use an abstract node, actually what you
> > are saying is "I want something of type t, the has the capabilities c,
> and
> > requires r. regarding the internals, I don't care, I just want it to
> work".
> > So actually, selecting a specific substituting template (as long as the
> > type, the requirements and the capabilities are as expected, of course),
> is
> > somewhat against the spirit of the substitution mapping feature.
> >
> > 2) I'm sorry, but I didn't get to the bottom of your question. Could you
> > elaborate a bit more, and include a small example?
> >
> >
> >
> >
> > On Thu, Aug 31, 2017 at 11:35 AM, D Jayachandran <
> > d.jayachandran@ericsson.com> wrote:
> >
> > > Hi,
> > >
> > > With respect to substituting stored service templates, I have few
> things
> > > to be clarified
> > >
> > > 1) Handling substitution when multiple service templates matches for
> the
> > > abstract node type .
> > >         Would the 1st match would be used for substitution  or Are we
> > > looking at policy to enable user to select particular service templates
> > for
> > > substitution with multiple service templates ?
> > > 2) Custom node types as abstract node type.
> > >         With custom node types as abstract node type, there seems to
> be a
> > > need to implicitly import that custom node type in our top level
> service
> > > template so that the parser recognizes this custom type.
> > >         Assuming the abstract node type would be substituted from a
> > stored
> > > substituting service template, we need to at least import the custom
> node
> > > types and have it part of the same CSAR package.
> > >         Would this be a challenge for the top-level service template
> > > author in including and importing the custom node types as abstraction
> ?
> > or
> > > Is this how we are looking at custom node types ?
> > >         Is it possible to identify an abstract node during parsing ,
> such
> > > as if it does not contain any implementation ( The SPEC does not say
> > > anything on this )?
> > >
> > > Regards,
> > > DJ
> > > -----Original Message-----
> > > From: Ran Ziv [mailto:ran@cloudify.co]
> > > Sent: Wednesday, August 16, 2017 6:19 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Service Composition / Substitution Mapping
> > >
> > > I agree, especially when the benefit of being able to use an existing
> > > service - yet only one which hasn't been deployed via a workflow -
> > doesn't
> > > seem all that interesting IMO.
> > >
> > > Another concern I could add to the ones you've mentioned is the
> service's
> > > inputs - the substituting template's inputs should be received via the
> > > properties of the abstract node in the top level service template. If
> the
> > > service already exists, these inputs would not be passed as expected.
> > >
> > > Ran
> > >
> > > On Wed, Aug 16, 2017 at 3:25 PM, D Jayachandran <
> > > d.jayachandran@ericsson.com
> > > > wrote:
> > >
> > > > Hi Ran,
> > > >
> > > > When Tal mentioned about "substituting service", I thought it was
> > > > about the services which dint have any associated
> executions/workflows
> > > triggered.
> > > > Am also in favor of  "substituting service templates" rather than
> > > > "substituting service".
> > > > With "substituting service" approach (when the service is not
> > > > instantiated), I see some open points
> > > >         - In a multi-user scenario, what will happen when a service
> is
> > > > composed using the substituting service and at the sametime a
> > > > workflow is triggered for the substituting service. ?
> > > >         - Is it okay to delete(dissolve) the substituting service
> > > > after it is used to create the composed service. ?
> > > >
> > > > Starting with it might be a good idea to only have "substituting
> > > > service templates" approach.
> > > >
> > > > Regards,
> > > > DJ
> > > > -----Original Message-----
> > > > From: Ran Ziv [mailto:ran@cloudify.co]
> > > > Sent: Wednesday, August 16, 2017 4:29 PM
> > > > To: dev@ariatosca.incubator.apache.org
> > > > Subject: Re: Service Composition / Substitution Mapping
> > > >
> > > > I'd say right now we're looking at "static service composition" which
> > > > is only about "substituting service templates", not "substituting
> > > > service". If a service is already running, it will not be used.
> > > >
> > > > I think what Tal meant was that each service template - whether the
> > > > top level one or one of the substituting templates - needs to resolve
> > > > its inner reqs&caps internally first, and then resolve substitution
> > > > reqs&caps across service templates.
> > > >
> > > >
> > > > On Wed, Aug 16, 2017 at 12:00 PM, D Jayachandran <
> > > > d.jayachandran@ericsson.com> wrote:
> > > >
> > > > > Hi Tal,
> > > > >
> > > > > Thanks for organizing the points.
> > > > > So if I understand correctly we are looking only at "Static service
> > > > > composition" which includes "substituting service template" and
> > > > > "substituting service".
> > > > >
> > > > > As you said with "substituting service template" approach ,we will
> > > > > have all the nodes aggregated from other service templates and a
> > > > > single workflow would be triggered to perform life-cycle operation
> > > > > on
> > > > all the nodes.
> > > > > Am not sure why the workflows needs to be "boundary aware" for
> nodes
> > > > > being substituted ? I see nodes are already part of the composed
> > > > > service, Could you please help me understand this ?
> > > > >
> > > > >
> > > > > Regards,
> > > > > DJ
> > > > > -----Original Message-----
> > > > > From: Tal Liron [mailto:tal@cloudify.co]
> > > > > Sent: Saturday, August 12, 2017 4:52 AM
> > > > > To: dev@ariatosca.incubator.apache.org
> > > > > Subject: Re: Service Composition / Substitution Mapping
> > > > >
> > > > > You are correct -- to participate in this "multi-VIM" scenario, the
> > > > > Openstack plugin would have to know how to translate the TOSCA
> > > > > properties to a flavor ID. This could all be done in 100% TOSCA via
> > > > > policies (say, an aria.Openstack).
> > > > >
> > > > > Doing this automatically might not be a good idea, or even
> necessary.
> > > > > Worst case is you get a validation error if the ARIA plugin can't
> > > > > find a flavor in the table to match your requirements, in which you
> > > > > case you can go and manually find the right ID and add it to the
> > table.
> > > > >
> > > > > And I agree about being fine with imperfection: the rule of thumb
> > > > > for our work is always to allow for sensible defaults even if no
> > > > > explicit policy is given.
> > > > >
> > > > > Anyway, we've gone way off the topic of this thread. We can talk
> > > > > about it more once it comes closer to an implementation.
> > > > >
> > > > > On Fri, Aug 11, 2017 at 3:52 PM, DeWayne Filppi
> > > > > <dewayne@cloudify.co>
> > > > > wrote:
> > > > >
> > > > > > Interesting.  Take Openstack (please <rim shot>).  If you model a
> > > > > > compute OS as explicitly as you like, there still has to be a
> > "match"
> > > > > > to an Openstack image ID.  Or are you saying you must supply the
> > > > > > image
> > > > > ID for
> > > > > > OSs.   Likewise, you can't supply RAM and CPUs without a flavor
> ID.
> > > > > > Openstack does allow for custom flavors, but I doubt the plugin
> is
> > > > > > doing that.  Much better to have a "caps-init" interface in some
> > > > > > low down base type that can be triggered at service creation to
> > > > > > support reqs/caps (IMHO).  Then the plugin can verify whether the
> > > > > > service can be construct based on fuzzy constraints.  Maybe this
> > > > > > is a case that the "general solution" is a nightmare of
> > > > > > complexity, but having a plugin scan the available flavors to
> make
> > > > > > sure a requirement can be met doesn't seem that tough.  If TOSCA
> > > > > > provided a formal lifecycle interface for it, then orchestrators
> > > > > > or just plugins could determine how tricky they wanted to be.
> > > > > > IOW, let not the perfect be the enemy of
> > > > > the good.
> > > > > >
> > > > > > DeWayne
> > > > > >
> > > > > >
> > > > > > On Fri, Aug 11, 2017 at 1:26 PM, Tal Liron <tal@cloudify.co>
> > wrote:
> > > > > >
> > > > > > > OK, that's a whole different can of worms. :)
> > > > > > >
> > > > > > > TOSCA's Compute capabilities (Container and OperatingSystem)
> are
> > > > > > explicit.
> > > > > > > You specify which OS you want, how much RAM you want, how many
> > > > > > > CPUs,
> > > > > etc.
> > > > > > > ARIA's explicit node types (for example, the AWS Compute node)
> > > > > > > are
> > > > > > likewise
> > > > > > > explicit. So there is not querying here: the plugin will
> attempt
> > > > > > > to spin
> > > > > > up
> > > > > > > exactly the virtual machine you asked for. If it fails, the
> > > > > > > workflow will fail.
> > > > > > >
> > > > > > > This is not good enough, I think, for real world scenarios.
> > > > > > > There are two possible solutions:
> > > > > > >
> > > > > > > 1) Support ranges or fallbacks. So instead of saying "I need 4
> > > > > > > GB of
> > > > > RAM"
> > > > > > > you can say "I would like 4 GB of RAM, but 2 GB would also be
> > OK."
> > > > > > There's
> > > > > > > no easy way to do this now without totally changing how the
> > > > > > > capability types are designed. But, it may be possible to
> > > > > > > override this via
> > > > > > policies.
> > > > > > > So, the capabilities would perhaps specify the minimal
> > > > > > > requirements,
> > > > > > while
> > > > > > > policies specify preferences. Some aspects of this were
> > > > > > > discussed in the OPEN-O project. DeWayne, has any of this
> > > > > > > survived in ONAP, or have we not reached that point in the
> > > discussion yet?
> > > > > > >
> > > > > > > 2) Incorporate this into the bigger topic of resource
> > > orchestration.
> > > > > > This a
> > > > > > > huge challenge for the industry. The problem field contains not
> > > > > > > just "I need X amount of RAM" but also "I want all my virtual
> > > > > > > machines and containers running on the same high-performance
> > > > > > > network backend and have these two nodes on the same bare-metal
> > > > > > > machine or at least in the same
> > > > > > data
> > > > > > > center rack with a NUMA interconnect, and I also don't want all
> > > > > > > this to cost more that $100 per hour." That's not crazy: these
> > > > > > > are real world requirements for high-performance VNFs and
> > > > > > > service
> > > > chaining.
> > > > > > > Resource orchestration requires a full map of what is available
> > > > > > > in the data
> > > > > > centers,
> > > > > > > a negotiation-based algorithm for properly allocating and
> > > > > > > placing resources, connection to billing services, etc. Of
> > > > > > > course resource orchestration is not within the scope of ARIA,
> > > > > > > but it would be great for ARIA to have plugins for them (and
> > > > > > > TOSCA be able to model resource requirement policies) when
> these
> > > become available.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Aug 11, 2017 at 3:02 PM, DeWayne Filppi
> > > > > > > <dewayne@cloudify.co>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > For the "resource realization" part, I was not even
> considering
> > > > > > > > multicloud/vim.   I was considering single cloud even outside
> > of
> > > > > > > > composition.  Just reqs and caps.  If my node "requires" a
> > > > > > > > compute node with Suse Linux version X with a minimum of 4GB
> > > > > > > > RAM, how does
> > > > > the
> > > > > > > > orchestrator match that without querying the cloud via the
> > > plugin?
> > > > >  If
> > > > > > > it
> > > > > > > > does query it, which it seems it must in addition to the
> > > > > > > > implicit quota query, how is this done?  TOSCA seems to not
> > > > > > > > really care, which is fine
> > > > > > > and
> > > > > > > > perhaps a good idea.  But ARIA has to care.
> > > > > > > >
> > > > > > > > DeWayne
> > > > > > > >
> > > > > > > > On Fri, Aug 11, 2017 at 12:34 PM, Tal Liron <tal@cloudify.co
> >
> > > > wrote:
> > > > > > > >
> > > > > > > > > In my opinion, the new composite service should indeed be a
> > > > > > > > > single
> > > > > > > > service,
> > > > > > > > > so the ARIA CLI will show it as one (if a substituting
> > > > > > > > > service
> > > > > > already
> > > > > > > > > existed, it would be "dissolved" into the new top-level
> > > > > > > > > service). The composition will show its traces if you look
> > > > > > > > > more deeply, because
> > > > > > > you'll
> > > > > > > > > see that some node templates come from a different service
> > > > > template.
> > > > > > > > > Perhaps our CLI can detect this and tell the user which
> > > > > > > > > service
> > > > > > > templates
> > > > > > > > > were used to create the nodes in current service.
> > > > > > > > >
> > > > > > > > > The rest of what you described I think is not related
> > > > > > > > > directly to
> > > > > > > service
> > > > > > > > > composition, but resource realization. The way we currently
> > > > > > > > > handle
> > > > > > this
> > > > > > > > is
> > > > > > > > > by being very explicit: you have to use the derived Compute
> > > > > > > > > types
> > > > > > > > included
> > > > > > > > > in our AWS or Openstack plugins, for example.
> > > > > > > > >
> > > > > > > > > I think we should still keep this, because sometimes you
> > > > > > > > > want to be
> > > > > > > very
> > > > > > > > > explicit (and use specific features of the platform), but I
> > > > > > > > > actually
> > > > > > > have
> > > > > > > > > some ideas for multi-VIM support that would work
> differently:
> > > > > > > > > the
> > > > > > idea
> > > > > > > is
> > > > > > > > > to use the basic Compute type, with detailed properties in
> > > > > > > > > its
> > > > > > > Container
> > > > > > > > > and OperatingSystem capabilities. There would then be a
> > > > > > > > > policy,
> > > > > > perhaps
> > > > > > > > > aria.Realization, that would hint at what kind of Compute
> > > > > > > > > nodes you
> > > > > > are
> > > > > > > > > looking for (you can apply the policy to specific nodes or
> > > > > > > > > groups, or generally). It might be possible to still have
> > > > > > > > > strong
> > > > > > platform-specific
> > > > > > > > > feature support here, perhaps by implementing a general
> > > > > > > > > string
> > > > > > > key-value
> > > > > > > > > dict that could include hints for the specific plugin to
> use.
> > > > > > > > >
> > > > > > > > > Anyway, just ideas at this point...
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Aug 11, 2017 at 2:25 PM, DeWayne Filppi
> > > > > > > > > <dewayne@cloudify.co
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Good stuff.  Obviously a "fancy include" was the wrong
> > > > metaphor.
> > > > > > The
> > > > > > > > > > lifecycles are linked though.  When a create the
> > > > > > > > > > referencing
> > > > > > service
> > > > > > > > > (aria
> > > > > > > > > > service create), ARIA will match the other service
> > > > > > > > > > template, and
> > > > > > run
> > > > > > > > > create
> > > > > > > > > > service on it, and then continue on.  Uninstall of the
> > > > > > > > > > referencer
> > > > > > > will
> > > > > > > > > > destroy the referenced service.  After such an
> > > > > > > > > > instantiation, would
> > > > > > > > > listing
> > > > > > > > > > all services produce two (perhaps with some parent
> > > > > > > > > > indicator) or
> > > > > > one?
> > > > > > > > > From
> > > > > > > > > > what I've seen, reqs and caps don't have the equivalent
> of
> > > > > > > > > > a
> > > > > > > lifecycle
> > > > > > > > > > interface associated.  Maybe I missed it.  It is implicit
> > > > > > > > > > in the orchestrator to match stuff up at service creation
> > > > > > > > > > time, I'm
> > > > > > > assuming,
> > > > > > > > > and
> > > > > > > > > > using plugins somehow?  The sort of flagship scenario is
> > > > > > > > > > matching
> > > > > > > cloud
> > > > > > > > > > compute resources without specifying an image.  Since
> > > > > > > > > > discovering
> > > > > > > > > whether a
> > > > > > > > > > particular cloud has a given capability, I guessing a
> > > > > > > > > > plugin for
> > > > > > that
> > > > > > > > > cloud
> > > > > > > > > > has to search cloud inventory and perhaps quota to
> provide
> > > > > > > > > > info for
> > > > > > > the
> > > > > > > > > > match.  Since plugins (at least the Cloudify variety)
> tend
> > > > > > > > > > to be
> > > > > > > > > triggered
> > > > > > > > > > due to operations that they connect to lifecycle methods,
> > > > > > > > > > and there
> > > > > > > is
> > > > > > > > no
> > > > > > > > > > "materialize_capabilities" interface that I noticed, some
> > > > > > > > > > other
> > > > > > kind
> > > > > > > of
> > > > > > > > > > magic must be performed.  Maybe this is an
> > > > > > > > > > orchestrator-specific
> > > > > > > detail
> > > > > > > > > > outside of TOSCA.
> > > > > > > > > >
> > > > > > > > > > DeWayne
> > > > > > > > > >
> > > > > > > > > > On Fri, Aug 11, 2017 at 10:57 AM, Tal Liron
> > > > > > > > > > <tal@cloudify.co>
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > OK, let me try to organize this differently. Three
> > > > > > > > > > > potential
> > > > > > > > > conceptions
> > > > > > > > > > > here:
> > > > > > > > > > >
> > > > > > > > > > > 1) A "fancy include," as you say. All that would happen
> > > > > > > > > > > here is
> > > > > > > that
> > > > > > > > > the
> > > > > > > > > > > TOSCA parser would automatically find the service
> > > > > > > > > > > template to
> > > > > > > include
> > > > > > > > > > from
> > > > > > > > > > > some kind of repository of recognized service
> templates,
> > > > > > > > > > > and just
> > > > > > > > > include
> > > > > > > > > > > that. The language in the TOSCA spec suggests that this
> > > > > > > > > > > is not
> > > > > > the
> > > > > > > > > > > intention: it is something that happens at the
> > > > "orchestrator,"
> > > > > > not
> > > > > > > > the
> > > > > > > > > > > "parser."
> > > > > > > > > > >
> > > > > > > > > > > 2) Static service composition. This happens not at the
> > > > > > > > > > > parsing
> > > > > > > stage,
> > > > > > > > > but
> > > > > > > > > > > rather the instantiation stage, where reqs-and-caps
> > > happens.
> > > > > > > > > > > I
> > > > > > > think
> > > > > > > > > this
> > > > > > > > > > > is what is intended: substitution mapping is
> > > > > > > > > > > specifically about
> > > > > > > > mapping
> > > > > > > > > > > reqs-and-caps. And this is also where things like
> > > > > > > > > > > scalability and
> > > > > > > > > > placement
> > > > > > > > > > > happen: think of a requirement matching a capability,
> > > > > > > > > > > but that
> > > > > > > > > capability
> > > > > > > > > > > not having enough capacity. So, the node might be able
> > > > > > > > > > > to scale
> > > > > > > out:
> > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > > case of substitution, this would mean duplicating an
> > > > > > > > > > > entire
> > > > > > service
> > > > > > > > > > > instance. My understanding is that this is what is
> > > > > > > > > > > intended by
> > > > > > > TOSCA,
> > > > > > > > > and
> > > > > > > > > > > it's entirely within the scope of what we can do. We've
> > > > > > > > > > > recently
> > > > > > > just
> > > > > > > > > > > refactored the instantiation phase into a new
> "topology"
> > > > > > > > > > > module
> > > > > > > where
> > > > > > > > > > > exactly all this logic is concentrated. So think of it
> > > > > > > > > > > this way
> > > > > > --
> > > > > > > > ARIA
> > > > > > > > > > has
> > > > > > > > > > > three parts: "parser," "topology manager," and
> "workflow
> > > > > engine"
> > > > > > > > > > > ("orchestrator").
> > > > > > > > > > >
> > > > > > > > > > > (I think I might have confused some thing here a bit
> > > > > > > > > > > when
> > > > > > > mentioning
> > > > > > > > a
> > > > > > > > > > > "logical proxy node." I do not mean an actual piece of
> > > > > > > > > > > proxy
> > > > > > > software
> > > > > > > > > > > running on a machine somewhere. I mean just a data
> point
> > > > > > > > > > > in the ARIA-generated topology that can be used as a
> > > > > > > > > > > barrier of sorts
> > > > > > when
> > > > > > > > > > > constructing the task graph -- because the task graph
> > > > > > > > > > > follows relationships, the edges of the topology. It
> > > > > > > > > > > could be that we
> > > > > > > > discover
> > > > > > > > > in
> > > > > > > > > > > our POC that this is not needed, because actually the
> > > > > > substitution
> > > > > > > > node
> > > > > > > > > > is
> > > > > > > > > > > already part of our topology data model and we might be
> > > > > > > > > > > able to
> > > > > > > > easily
> > > > > > > > > > take
> > > > > > > > > > > that into account when generating the task graph.)
> > > > > > > > > > >
> > > > > > > > > > > 3) Live service composition. I think this is a fantasy
> > > > > > > > > > > of some
> > > > > > > > people:
> > > > > > > > > > that
> > > > > > > > > > > ARIA would be able to take existing, "running" service
> > > > > > > > > > > chains and
> > > > > > > run
> > > > > > > > > > > workflows with them. I do think this is a solvable
> > > > > > > > > > > problem, but
> > > > > > not
> > > > > > > > via
> > > > > > > > > > > substitution mapping per se. A solution could involve
> > > > > > > > > > > deployment
> > > > > > > of a
> > > > > > > > > > proxy
> > > > > > > > > > > service (which could actually be encapsulated in a
> > > > > > > > > > > substitution
> > > > > > > > > mapping,
> > > > > > > > > > > but doesn't have to be), or configuring specialized
> > > > > > > > > > > virtual ports
> > > > > > > via
> > > > > > > > > an
> > > > > > > > > > > SDN controller, or via logical proxy nodes created via
> > > > > > > > > > > an
> > > > > > > inspection
> > > > > > > > > > tool,
> > > > > > > > > > > etc. I cannot believe that there is a one-size-fits-all
> > > > > > > > > > > solution
> > > > > > to
> > > > > > > > > this
> > > > > > > > > > > problem. The dream of NFV might be to have everything
> > > > > > > > > > > connect to
> > > > > > > each
> > > > > > > > > > other
> > > > > > > > > > > like LEGO blocks, but there are far too many protocols,
> > > > > > > > configuration,
> > > > > > > > > > and
> > > > > > > > > > > security standards. I think point #2, what I called
> > > > > > > > > > > "static
> > > > > > service
> > > > > > > > > > > composition," is a realistic compromise and within the
> > > > > > > > > > > scope of
> > > > > > > what
> > > > > > > > > > TOSCA
> > > > > > > > > > > promises.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Aug 11, 2017 at 12:08 PM, DeWayne Filppi <
> > > > > > > > dewayne@cloudify.co>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > 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
> > > > > > > > > > > > <tal@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
> > > > > > > > > > > > > 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.
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message