Re: Service Composition / Substitution Mapping

"directives" is just a list of strings. Moreover, it seems like a placeholder for something in the future. Also note that "directives" exist only for node templates, not node type, so this means that in order to use substitution we would have to have a node template marked as being abstract. If we

Re: Service Composition / Substitution Mapping

On Tue, Sep 5, 2017 at 6:09 PM, Tal Liron wrote: > > Just like you can specify a specific node template for a requirement, I > believe it can be useful and often necessary to specify a substituted > service template. > ​Even​ if it is needed, the question is how to do that.

RE: Service Composition / Substitution Mapping

Regards, DJ -Original Message- From: Tal Liron [mailto:t...@cloudify.co] Sent: Tuesday, September 05, 2017 8:30 PM To: dev@ariatosca.incubator.apache.org Subject: Re: Service Composition / Substitution Mapping On Tue, Sep 5, 2017 at 5:33 AM, D Jayachandran <d.jayachand...@ericss

Re: Service Composition / Substitution Mapping

On Sun, Sep 3, 2017 at 4:06 AM, Ran Ziv wrote: > 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

Re: Service Composition / Substitution Mapping

On Tue, Sep 5, 2017 at 5:33 AM, D Jayachandran wrote: > Hence I wanted to know if there is any possibility of identifying an > abstract type (during parsing )so that we need not import or define the > custom node type in my service template. > In my opinion, the

RE: Service Composition / Substitution Mapping

cloudify.co] Sent: Sunday, September 03, 2017 2:36 PM To: dev@ariatosca.incubator.apache.org Subject: Re: Service Composition / Substitution Mapping 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 explicit

Re: Service Composition / Substitution Mapping

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 abstr

Re: Service Composition / Substitution Mapping

ice". > > > 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 s

Re: Service Composition / Substitution Mapping

PEC does not say > anything on this )? > > Regards, > DJ > -Original Message- > From: Ran Ziv [mailto:r...@cloudify.co] > Sent: Wednesday, August 16, 2017 6:19 PM > To: dev@ariatosca.incubator.apache.org > Subject: Re: Service Composition / Substitution Mapping > &

RE: Service Composition / Substitution Mapping

on this )? Regards, DJ -Original Message- From: Ran Ziv [mailto:r...@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

Re: Service Composition / Substitution Mapping

Original Message- > From: Ran Ziv [mailto:r...@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 > on

RE: Service Composition / Substitution Mapping

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"

Re: Service Composition / Substitution Mapping

ady part of the composed service, Could > you please help me understand this ? > > > Regards, > DJ > -Original Message- > From: Tal Liron [mailto:t...@cloudify.co] > Sent: Saturday, August 12, 2017 4:52 AM > To: dev@ariatosca.incubator.apache.org > Subject: Re: Serv

Re: Service Composition / Substitution Mapping

ady part of the composed service, Could > you please help me understand this ? > > > Regards, > DJ > -Original Message- > From: Tal Liron [mailto:t...@cloudify.co] > Sent: Saturday, August 12, 2017 4:52 AM > To: dev@ariatosca.incubator.apache.org > Subject: Re: Serv

RE: Service Composition / Substitution Mapping

of the composed service, Could you please help me understand this ? Regards, DJ -Original Message- From: Tal Liron [mailto:t...@cloudify.co] Sent: Saturday, August 12, 2017 4:52 AM To: dev@ariatosca.incubator.apache.org Subject: Re: Service Composition / Substitution Mapping You are corr

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

Re: Service Composition / Substitution Mapping

Interesting. Take Openstack (please ). 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

Re: Service Composition / Substitution Mapping

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

Re: Service Composition / Substitution Mapping

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

Re: Service Composition / Substitution Mapping

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

Re: Service Composition / Substitution Mapping

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

Re: Service Composition / Substitution Mapping

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

Re: Service Composition / Substitution Mapping

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

Re: Service Composition / Substitution Mapping

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

RE: Service Composition / Substitution Mapping

2017 10:09 PM To: dev@ariatosca.incubator.apache.org 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 al

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 >

RE: Service Composition / Substitution Mapping

ednesday, August 09, 2017 6:28 PM To: dev@ariatosca.incubator.apache.org Subject: Re: Service Composition / Substitution Mapping Currently, the support for substitution mapping is extremely limited. the substitution_mapping section is parsed and validated, but nothing more. However, supporting thi

Re: Service Composition / Substitution Mapping

17 8:41 PM > To: dev@ariatosca.incubator.apache.org > Subject: Re: Service Composition / Substitution Mapping > > Well, this is exactly what policies are for. :) > > Again, I think the rule of thumb should be that users put policies in place > *only* if the defaults do not suffi

RE: Service Composition / Substitution Mapping

or set of guidelines for using substitution mapping today? Or should I avoid it completely for now? - Steve B -Original Message- From: Tal Liron [mailto:t...@cloudify.co] Sent: Monday, August 07, 2017 8:41 PM To: dev@ariatosca.incubator.apache.org Subject: Re: Service Composition

Re: Service Composition / Substitution Mapping

Well, this is exactly what policies are for. :) Again, I think the rule of thumb should be that users put policies in place *only* if the defaults do not suffice. On Mon, Aug 7, 2017 at 6:42 PM, Ran Ziv wrote: > The sensible defaults Tal's mentioned sound indeed sensible to

Re: Service Composition / Substitution Mapping

The sensible defaults Tal's mentioned sound indeed sensible to me. I'd also like users to have control over this, though I'm a bit worried about us getting too carried away with how arbitrarily we use policies for configuring, well, pretty much anything. It might not be a problem right now but I'm

Re: Service Composition / Substitution Mapping

Our goal with adding new "conventions" to ARIA, such as policies, is to always make them optional. The idea is that a plain-vanilla TOSCA template would "just work" in ARIA via sensible defaults. The extra stuff is there if you know you are using ARIA and you want to make use of its features. (The

Re: Service Composition / Substitution Mapping

Cool. Missed that. That leaves things almost completely wide open from the orchestrator side, IOW few predefined keys. Too few IMHO, but if everyone uses ARIA conventions it could work. On Tue, Aug 1, 2017 at 11:49 PM, Tal Liron wrote: > I agree! Luckily metadata exists in

Re: Service Composition / Substitution Mapping

I agree! Luckily metadata exists in the 1.0 spec. :) http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/cos01/TOSCA-Simple-Profile-YAML-v1.0-cos01.html#_Toc379455044 On Tue, Aug 1, 2017 at 7:16 PM, DeWayne Filppi wrote: > It occurs that it might be useful to

Re: Service Composition / Substitution Mapping

It occurs that it might be useful to be able to tag service templates with arbitrary meta-data. Perhaps at one level carried forward from a CSAR manifest, but also user definable. This would allow inter-service references to be definitive, if desired. This could be implicitly defined as a

Re: Service Composition / Substitution Mapping

Thanks for the kudos. :) This topic was discussed on this list a while ago. It's indeed tricky to get right, because TOSCA leaves a lot of room for the orchestrator to implement. I'm thinking of it working something like this: 1. The reqs-and-caps engine by default will always look for