RE: Support for TOSCA Simple Profile NFV 1.0

[D Jayachandran]

Thanks for the update Avia.

Regards,
DJ

-Original Message-
From: Avia Efrat [mailto:a...@gigaspaces.com] 
Sent: Wednesday, June 07, 2017 3:03 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Support for TOSCA Simple Profile NFV 1.0

Hi DJ,

I've created a pull request for the issue that Tal opened:
https://github.com/apache/incubator-ariatosca/pull/147
I expect it to be merged on Thursday/Friday.

On Thu, Jun 1, 2017 at 7:02 PM, Tal Liron <t...@gigaspaces.com> wrote:

> Thanks DJ, I opened a new JIRA issue for this if you want to track it:
>
> https://issues.apache.org/jira/browse/ARIA-275
>
> It shouldn't be too hard to do, just some busy work in YAML. Anyone on 
> the mailing list want to tackle this?
>
> On Thu, Jun 1, 2017 at 4:53 AM, D Jayachandran < 
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi,
> >
> > I hope ARIA currently supports , TOSCA Simple Profile NFV 1.0 draft 03.
> > The Latest available TOSCA NFV profile is Simple profile NFV 1.0 
> > draft
> 04,
> > released on 11 May 2017.
> >
> > Could you kindly confirm the current level of support from ARIA for 
> > NFV profiles and do you have any timelines to support draft 04 ?
> >
> >
> > Regards,
> > DJ
> >
>
>
>
> --
> Tal Liron
> Senior Engineer
> t...@gigaspaces.com | +1 (773) 828-9339 Cloudify | 
> http://getcloudify.org 
> <http://getcloudify.org?utm_source=signaturesatori_
> medium=email_campaign=general_signature>
>
> <https://twitter.com/CloudifySource>
> <https://www.linkedin.com/groups/8467478>
> <https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
> [image: Azure Webinar]
> <http://getcloudify.org/webinars/Azure-plugin-for-
> cloudify-webinar.html?utm_source=signaturesatori_
> medium=email_campaign=general_signature>
>



--
Avia Efrat
SW Engineer
a...@gigaspaces.com | +972546204553
Cloudify | http://getcloudify.org
<http://getcloudify.org?utm_source=signaturesatori_medium=email_campaign=general_signature>

<https://twitter.com/CloudifySource>
<https://www.linkedin.com/groups/8467478>
<https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
[image: Azure Webinar]
<http://getcloudify.org/webinars/Azure-plugin-for-cloudify-webinar.html?utm_source=signaturesatori_medium=email_campaign=general_signature>

Plugin structure and specifications

[D Jayachandran]

Hi,

ARIA currently supports plugin based lifecycle operation. A plugin here refers 
to a python module packaged as a wagon archive.
I have few queries on how the plugin is being seen at this moment


? Do we have any specifications on the structure of plugin ?

? With the current state, a plugin can be referenced in different node types.

? Can a plugin also contain node types specific to its implementation ? If we 
can associate a plugin to specific node types there will not be need to import 
the node types in our service template every time.

We think bundling node types as part of plugin and having them available to 
those service templates using the plugins would be a good option. Do you have 
any suggestions regarding this ? Do you already have something on this in your 
roadmap ?


Regards,
DJ

RE: Query on operation inputs

[D Jayachandran]

Hi Tal,

Please find below the git repo of my example.

https://github.com/djay8887/Aria-operationInputs

regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@gigaspaces.com] 
Sent: Thursday, June 01, 2017 9:59 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Query on operation inputs

I'm still a bit confused by all this. DJ, could you possibly create a quick git 
repo with your complete example to make sure we're all on the same page here?

On Thu, Jun 1, 2017 at 7:10 AM, Ran Ziv <r...@gigaspaces.com> wrote:

> Right, it makes more sense now :) But now I simply have to say again 
> that as far as I can tell this should in fact be the intended behavior.
>
> What would you rather happen? the "labels" parameter be assigned with 
> "None" instead?
> We considered this but part of the problem here is that the 
> information about whether an input is required or not is no longer 
> available at this stage so it's impossible to know whether to use "None" or 
> raise an error.
> Tal and I have talked about it in the past, and from what I remember, 
> Tal said the "required" field information in fact should not be 
> stored, and is only relevant for parsing phase. It is possible I'm 
> getting this wrong though :)
>
> I'm open for changes here as it is a somewhat confusing behavior - 
> although I think it does make sense after all.
>
>
>
> On Thu, Jun 1, 2017 at 3:04 PM, D Jayachandran < 
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi Ran/Tal,
> >
> > I was wrong, Tal's branch still throws the validation error (I was
> loading
> > a different service template) :). So the issue which I told still 
> > exists
> >
> > [root@DJ-DEV tal-test]# python /root/tal-test/incubator-
> ariatosca/aria/cli/main.py
> > executions start install -s s2
> > Declared parameters "labels" have not been provided values
> >
> > Regards,
> > DJ
> >
> > -Original Message-
> > From: Ran Ziv [mailto:r...@gigaspaces.com]
> > Sent: Thursday, June 01, 2017 5:24 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Query on operation inputs
> >
> > Again, there's a difference between the "required" validation and 
> > the actual runtime validation. the runtime one cannot be done during 
> > instantiation phase, which is why there are two separate validations.
> >
> > I do not know how come Tal's branch (which by now has been merged to
> > master) helped fixing your issue, so I might have misunderstood 
> > something about your problem :)
> >
> > Ran
> >
> > On Thu, Jun 1, 2017 at 2:11 PM, D Jayachandran < 
> > d.jayachand...@ericsson.com>
> > wrote:
> >
> > > Hi Tal,
> > >
> > > I did test your branch  https://github.com/apache/ 
> > > incubator-ariatosca/tree/ARIA-149-functions-in-operation-configura
> > > tion and it seems to have the fix for operation/interface inputs.
> > >
> > > Regards,
> > > DJ
> > > -Original Message-
> > > From: D Jayachandran
> > > Sent: Thursday, June 01, 2017 4:40 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: RE: Query on operation inputs
> > >
> > > Hi Ran,
> > >
> > > The validation of operation inputs is also done during instantiation.
> > > Please find below.
> > >
> > > [root@DJ-DEV tal-test]# python
> > > /root/tal-test/incubator-ariatosca/aria/cli/main.py
> > > service-templates store /root/tosca_simple_yaml_ 
> > > plugin/kubernetes-deployment.yaml st-3 Storing service template
> st-3...
> > > Validation issues:
> > >   4: interface definition "Standard" does not assign a value to a 
> > > required operation input "create.name" in "web_app"
> > >
> > > @"/root/tosca_simple_yaml_plugin/kubernetes-deployment.yaml":64:25
> > > Failed to parse service template
> > >
> > >
> > > I think the branch Tal provided  https://github.com/apache/ 
> > > incubator-ariatosca/tree/ARIA-149-functions-in-operation-configura
> > > tion has fixed the issue on operation inputs.
> > >
> > > Regards,
> > > DJ
> > >
> > > -Original Message-
> > > From: Ran Ziv [mailto:r...@gigaspaces.com]
> > > Sent: Thursday, June 01, 2017 2:27 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Query on operation inputs
> > >
> > > I think there's some confusion about di

RE: Query related to substitution mapping

[D Jayachandran]

Hi Ran/Tal,

Thanks for the information. It's good to know you already have this as part of 
your backlog.
We just need to know if you have plans to include this in your upcoming release 
?


Regards,
DJ
-Original Message-
From: Ran Ziv [mailto:r...@gigaspaces.com] 
Sent: Thursday, June 01, 2017 10:01 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Query related to substitution mapping

i agree for the most part, although I don't see it as part of the instantiation 
phase refactoring, but rather as a completely separate feature which I'd like 
us to work on in the near future.

On Thu, Jun 1, 2017 at 7:27 PM, Tal Liron  wrote:

> Your expectations are reasonable: that ARIA would look at all of its 
> current service instances and try to match reqs-and-caps with 
> substitutions.
>
> However, we are a bit far from implementing this. Currently, ARIA only 
> knows how to match reqs-and-caps within the service.
>
> Also, this feature has to be planned rather carefully: in some cases 
> the user will not want such automatic matching to happen with services 
> that just happen to exist in ARIA's db. I think this a great place to 
> introduce a new Policy that would allow the user to configure exactly 
> how matching would happen: should the matching prefer external 
> substitutions over internal nodes? are there limited to how many could 
> be matched? (like the "occurrences" definition in Capability) should 
> matching only happen with services of a certain csar/template? etc.
>
> ​We are planning some work ahead to refactor the way we instantiate 
> services, and I think at least some parts of this feature should be 
> included in that.
>

RE: Query on operation inputs

[D Jayachandran]

Hi Ran/Tal,

I was wrong, Tal's branch still throws the validation error (I was loading a 
different service template) :). So the issue which I told still exists

[root@DJ-DEV tal-test]# python 
/root/tal-test/incubator-ariatosca/aria/cli/main.py executions start install -s 
s2
Declared parameters "labels" have not been provided values

Regards,
DJ

-Original Message-
From: Ran Ziv [mailto:r...@gigaspaces.com] 
Sent: Thursday, June 01, 2017 5:24 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Query on operation inputs

Again, there's a difference between the "required" validation and the actual 
runtime validation. the runtime one cannot be done during instantiation phase, 
which is why there are two separate validations.

I do not know how come Tal's branch (which by now has been merged to
master) helped fixing your issue, so I might have misunderstood something about 
your problem :)

Ran

On Thu, Jun 1, 2017 at 2:11 PM, D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Hi Tal,
>
> I did test your branch  https://github.com/apache/ 
> incubator-ariatosca/tree/ARIA-149-functions-in-operation-configuration
> and it seems to have the fix for operation/interface inputs.
>
> Regards,
> DJ
> -Original Message-
> From: D Jayachandran
> Sent: Thursday, June 01, 2017 4:40 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: Query on operation inputs
>
> Hi Ran,
>
> The validation of operation inputs is also done during instantiation.
> Please find below.
>
> [root@DJ-DEV tal-test]# python 
> /root/tal-test/incubator-ariatosca/aria/cli/main.py
> service-templates store /root/tosca_simple_yaml_ 
> plugin/kubernetes-deployment.yaml st-3 Storing service template st-3...
> Validation issues:
>   4: interface definition "Standard" does not assign a value to a 
> required operation input "create.name" in "web_app"
>  
> @"/root/tosca_simple_yaml_plugin/kubernetes-deployment.yaml":64:25
> Failed to parse service template
>
>
> I think the branch Tal provided  https://github.com/apache/ 
> incubator-ariatosca/tree/ARIA-149-functions-in-operation-configuration
> has fixed the issue on operation inputs.
>
> Regards,
> DJ
>
> -Original Message-
> From: Ran Ziv [mailto:r...@gigaspaces.com]
> Sent: Thursday, June 01, 2017 2:27 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Query on operation inputs
>
> I think there's some confusion about different types of inputs. The 
> validation on inputs that is done during parsing (actually 
> "instantiation") stage is for the service's inputs, not operations.
> Execution and operation inputs (or more broadly, arguments) are 
> validated before an execution is run.
>
>
> On Tue, May 30, 2017 at 8:48 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi Ran,
> >
> > I think Tal as updated, it might be possibly a bug here. May be we 
> > all should come to common understanding.
> >
> > As I updated earlier, since the inputs validation are completing 
> > during parsing stage, I don’t feel why the validation is required 
> > again during orchestration time ?
> > Does the TOSCA spec actually refers the 2nd points of yours ? (The 
> > operation inputs must either have a default value in the type 
> > definition or be supplied with a value in the actual operation
> > definition)
> >
> >
> > Regards,
> > DJ
> >
> > -Original Message-
> > From: Ran Ziv [mailto:r...@gigaspaces.com]
> > Sent: Sunday, May 28, 2017 6:14 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Query on operation inputs
> >
> > I've reviewed your example, and I think either I'm missing something 
> > or my original explanation still applies:
> >
> >   1. The validation at orchestration time for whether required 
> > inputs have been specified does not deal with the "required" flag at 
> > all (actually, the flag never makes it past the parsing stage and 
> > into the
> storage models).
> >
> >   2. For operation inputs to validate successfully, each input must 
> > either have a default value in the type definition or be supplied 
> > with a value in the actual operation definition. In your case, both 
> > "labels" and "isService" for example didn't have a default value set 
> > in the type definition (as opposed to "target_host" for example) -
> However, "isService"
> > was set to "true" in the actual operation definition, while "labels"
> > wasn't assigned with any such value 

RE: Query on operation inputs

[D Jayachandran]

Hi Tal,

I did test your branch  
https://github.com/apache/incubator-ariatosca/tree/ARIA-149-functions-in-operation-configuration
 and it seems to have the fix for operation/interface inputs.

Regards,
DJ
-Original Message-
From: D Jayachandran 
Sent: Thursday, June 01, 2017 4:40 PM
To: dev@ariatosca.incubator.apache.org
Subject: RE: Query on operation inputs

Hi Ran,

The validation of operation inputs is also done during instantiation. Please 
find below.

[root@DJ-DEV tal-test]# python 
/root/tal-test/incubator-ariatosca/aria/cli/main.py service-templates store 
/root/tosca_simple_yaml_plugin/kubernetes-deployment.yaml st-3 Storing service 
template st-3...
Validation issues:
  4: interface definition "Standard" does not assign a value to a required 
operation input "create.name" in "web_app"
 @"/root/tosca_simple_yaml_plugin/kubernetes-deployment.yaml":64:25
Failed to parse service template


I think the branch Tal provided  
https://github.com/apache/incubator-ariatosca/tree/ARIA-149-functions-in-operation-configuration
 has fixed the issue on operation inputs.

Regards,
DJ

-Original Message-
From: Ran Ziv [mailto:r...@gigaspaces.com]
Sent: Thursday, June 01, 2017 2:27 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Query on operation inputs

I think there's some confusion about different types of inputs. The validation 
on inputs that is done during parsing (actually "instantiation") stage is for 
the service's inputs, not operations.
Execution and operation inputs (or more broadly, arguments) are validated 
before an execution is run.


On Tue, May 30, 2017 at 8:48 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Ran,
>
> I think Tal as updated, it might be possibly a bug here. May be we all 
> should come to common understanding.
>
> As I updated earlier, since the inputs validation are completing 
> during parsing stage, I don’t feel why the validation is required 
> again during orchestration time ?
> Does the TOSCA spec actually refers the 2nd points of yours ? (The 
> operation inputs must either have a default value in the type 
> definition or be supplied with a value in the actual operation
> definition)
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Ran Ziv [mailto:r...@gigaspaces.com]
> Sent: Sunday, May 28, 2017 6:14 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Query on operation inputs
>
> I've reviewed your example, and I think either I'm missing something 
> or my original explanation still applies:
>
>   1. The validation at orchestration time for whether required inputs 
> have been specified does not deal with the "required" flag at all 
> (actually, the flag never makes it past the parsing stage and into the 
> storage models).
>
>   2. For operation inputs to validate successfully, each input must 
> either have a default value in the type definition or be supplied with 
> a value in the actual operation definition. In your case, both 
> "labels" and "isService" for example didn't have a default value set 
> in the type definition (as opposed to "target_host" for example) - However, 
> "isService"
> was set to "true" in the actual operation definition, while "labels"
> wasn't assigned with any such value - Which is why you received the 
> validation error for a missing required input over the "labels"
> operation input.
>
>
> Does this make sense?
>
>
> On Fri, May 26, 2017 at 7:26 PM, Tal Liron <t...@gigaspaces.com> wrote:
>
> > OK, I see now -- the error you are getting is about the operation 
> > inputs, not the topology inputs which are different.
> >
> > You may have discovered a bug here. It seems like you're doing the 
> > right thing and giving values to all these inputs, so it should not 
> > be complaining.
> >
> > I am actually working on a PR right now that makes some significant 
> > changes to this mechanism, but it's not merged yet. I don't mean to 
> > waste your time, but I would appreciate if you could test it out for 
> > me in your environment. Here is the branch to use:
> >
> > https://github.com/apache/incubator-ariatosca/tree/ARIA-
> > 149-functions-in-operation-configuration
> >
> >
> > On Fri, May 26, 2017 at 4:53 AM, D Jayachandran < 
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Hi Tal,
> > >
> > > Thanks for your email.
> > >
> > > With the same example you took with my inputs "isService" & "image".
> > > ARIA has a problem when I don’t specify "isService" which 

RE: Query on operation inputs

[D Jayachandran]

Hi Ran,

The validation of operation inputs is also done during instantiation. Please 
find below.

[root@DJ-DEV tal-test]# python 
/root/tal-test/incubator-ariatosca/aria/cli/main.py service-templates store 
/root/tosca_simple_yaml_plugin/kubernetes-deployment.yaml st-3
Storing service template st-3...
Validation issues:
  4: interface definition "Standard" does not assign a value to a required 
operation input "create.name" in "web_app"
 @"/root/tosca_simple_yaml_plugin/kubernetes-deployment.yaml":64:25
Failed to parse service template


I think the branch Tal provided  
https://github.com/apache/incubator-ariatosca/tree/ARIA-149-functions-in-operation-configuration
 has fixed the issue on operation inputs.

Regards,
DJ

-Original Message-
From: Ran Ziv [mailto:r...@gigaspaces.com] 
Sent: Thursday, June 01, 2017 2:27 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Query on operation inputs

I think there's some confusion about different types of inputs. The validation 
on inputs that is done during parsing (actually "instantiation") stage is for 
the service's inputs, not operations.
Execution and operation inputs (or more broadly, arguments) are validated 
before an execution is run.


On Tue, May 30, 2017 at 8:48 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Ran,
>
> I think Tal as updated, it might be possibly a bug here. May be we all 
> should come to common understanding.
>
> As I updated earlier, since the inputs validation are completing 
> during parsing stage, I don’t feel why the validation is required 
> again during orchestration time ?
> Does the TOSCA spec actually refers the 2nd points of yours ? (The 
> operation inputs must either have a default value in the type 
> definition or be supplied with a value in the actual operation 
> definition)
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Ran Ziv [mailto:r...@gigaspaces.com]
> Sent: Sunday, May 28, 2017 6:14 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Query on operation inputs
>
> I've reviewed your example, and I think either I'm missing something 
> or my original explanation still applies:
>
>   1. The validation at orchestration time for whether required inputs 
> have been specified does not deal with the "required" flag at all 
> (actually, the flag never makes it past the parsing stage and into the 
> storage models).
>
>   2. For operation inputs to validate successfully, each input must 
> either have a default value in the type definition or be supplied with 
> a value in the actual operation definition. In your case, both 
> "labels" and "isService" for example didn't have a default value set 
> in the type definition (as opposed to "target_host" for example) - However, 
> "isService"
> was set to "true" in the actual operation definition, while "labels"
> wasn't assigned with any such value - Which is why you received the 
> validation error for a missing required input over the "labels" 
> operation input.
>
>
> Does this make sense?
>
>
> On Fri, May 26, 2017 at 7:26 PM, Tal Liron <t...@gigaspaces.com> wrote:
>
> > OK, I see now -- the error you are getting is about the operation 
> > inputs, not the topology inputs which are different.
> >
> > You may have discovered a bug here. It seems like you're doing the 
> > right thing and giving values to all these inputs, so it should not 
> > be complaining.
> >
> > I am actually working on a PR right now that makes some significant 
> > changes to this mechanism, but it's not merged yet. I don't mean to 
> > waste your time, but I would appreciate if you could test it out for 
> > me in your environment. Here is the branch to use:
> >
> > https://github.com/apache/incubator-ariatosca/tree/ARIA-
> > 149-functions-in-operation-configuration
> >
> >
> > On Fri, May 26, 2017 at 4:53 AM, D Jayachandran < 
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Hi Tal,
> > >
> > > Thanks for your email.
> > >
> > > With the same example you took with my inputs "isService" & "image".
> > > ARIA has a problem when I don’t specify "isService" which is 
> > > defined as
> > > required: false.
> > >
> > > Please find just the different inputs used in my example ( 
> > > topology, node type  and node template)
> > >
> > > TOPOLOGY INPUTS
> > >
> > > inputs:
> > > web_app_name:
> > > type: st

Support for TOSCA Simple Profile NFV 1.0

[D Jayachandran]

Hi,

I hope ARIA currently supports , TOSCA Simple Profile NFV 1.0 draft 03.
The Latest available TOSCA NFV profile is Simple profile NFV 1.0 draft 04, 
released on 11 May 2017.

Could you kindly confirm the current level of support from ARIA for NFV 
profiles and do you have any timelines to support draft 04 ?


Regards,
DJ

RE: Query on operation inputs

[D Jayachandran]

Hi Ran,

I think Tal as updated, it might be possibly a bug here. May be we all should 
come to common understanding.

As I updated earlier, since the inputs validation are completing during parsing 
stage, I don’t feel why the validation is required again during orchestration 
time ?
Does the TOSCA spec actually refers the 2nd points of yours ? (The operation 
inputs must either have a default value in the type definition or be supplied 
with a value in the actual operation definition)


Regards,
DJ

-Original Message-
From: Ran Ziv [mailto:r...@gigaspaces.com] 
Sent: Sunday, May 28, 2017 6:14 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Query on operation inputs

I've reviewed your example, and I think either I'm missing something or my 
original explanation still applies:

  1. The validation at orchestration time for whether required inputs have been 
specified does not deal with the "required" flag at all (actually, the flag 
never makes it past the parsing stage and into the storage models).

  2. For operation inputs to validate successfully, each input must either have 
a default value in the type definition or be supplied with a value in the 
actual operation definition. In your case, both "labels" and "isService" for 
example didn't have a default value set in the type definition (as opposed to 
"target_host" for example) - However, "isService"
was set to "true" in the actual operation definition, while "labels" wasn't 
assigned with any such value - Which is why you received the validation error 
for a missing required input over the "labels" operation input.


Does this make sense?


On Fri, May 26, 2017 at 7:26 PM, Tal Liron <t...@gigaspaces.com> wrote:

> OK, I see now -- the error you are getting is about the operation 
> inputs, not the topology inputs which are different.
>
> You may have discovered a bug here. It seems like you're doing the 
> right thing and giving values to all these inputs, so it should not be 
> complaining.
>
> I am actually working on a PR right now that makes some significant 
> changes to this mechanism, but it's not merged yet. I don't mean to 
> waste your time, but I would appreciate if you could test it out for 
> me in your environment. Here is the branch to use:
>
> https://github.com/apache/incubator-ariatosca/tree/ARIA-
> 149-functions-in-operation-configuration
>
>
> On Fri, May 26, 2017 at 4:53 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi Tal,
> >
> > Thanks for your email.
> >
> > With the same example you took with my inputs "isService" & "image". 
> > ARIA has a problem when I don’t specify "isService" which is defined 
> > as
> > required: false.
> >
> > Please find just the different inputs used in my example ( topology, 
> > node type  and node template)
> >
> > TOPOLOGY INPUTS
> >
> > inputs:
> > web_app_name:
> > type: string
> > value: tosca-webapp
> >
> > web_app_image:
> > type: string
> > value: kuber-master:5000/webwithdbinput
> >
> > web_app_port:
> > type: integer
> > value: 80
> >
> > db_name:
> > type: string
> > value: tosca-database
> >
> > db_image:
> > type: string
> > value: kuber-master:5000/dbforweb
> >
> > db_port:
> > type: integer
> > value: 3306
> >
> >
> > NODE-TYPE INPUTS
> >
> > create:
> > inputs:
> > name:
> > type: string
> > required: true
> > image:
> > type: string
> > required: true
> > exposed_port:
> > type: integer
> > required: false
> > target_port:
> > type: integer
> > required: false
> > default: 8080
> > target_host:
> > type: string
> > required: false
> > default: test
> > labels:
> > type: string
>

RE: Query on operation inputs

[D Jayachandran]

Thanks Tal.

I will try to use your branch and let you know the results.

Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@gigaspaces.com] 
Sent: Friday, May 26, 2017 9:57 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Query on operation inputs

OK, I see now -- the error you are getting is about the operation inputs, not 
the topology inputs which are different.

You may have discovered a bug here. It seems like you're doing the right thing 
and giving values to all these inputs, so it should not be complaining.

I am actually working on a PR right now that makes some significant changes to 
this mechanism, but it's not merged yet. I don't mean to waste your time, but I 
would appreciate if you could test it out for me in your environment. Here is 
the branch to use:

https://github.com/apache/incubator-ariatosca/tree/ARIA-149-functions-in-operation-configuration


On Fri, May 26, 2017 at 4:53 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Tal,
>
> Thanks for your email.
>
> With the same example you took with my inputs "isService" & "image". 
> ARIA has a problem when I don’t specify "isService" which is defined 
> as
> required: false.
>
> Please find just the different inputs used in my example ( topology, 
> node type  and node template)
>
> TOPOLOGY INPUTS
>
> inputs:
> web_app_name:
> type: string
> value: tosca-webapp
>
> web_app_image:
> type: string
> value: kuber-master:5000/webwithdbinput
>
> web_app_port:
> type: integer
> value: 80
>
> db_name:
> type: string
> value: tosca-database
>
> db_image:
> type: string
> value: kuber-master:5000/dbforweb
>
> db_port:
> type: integer
> value: 3306
>
>
> NODE-TYPE INPUTS
>
> create:
> inputs:
> name:
> type: string
> required: true
> image:
> type: string
> required: true
> exposed_port:
> type: integer
> required: false
> target_port:
> type: integer
> required: false
> default: 8080
> target_host:
> type: string
> required: false
> default: test
> labels:
> type: string
> required: false
> isService:
> type: boolean
> required: false
>
> NODE-TEMPLATE INPUTS
>
> interfaces:
> Standard:
> create:
> inputs:
> name: { get_input: web_app_name }
> image: { get_property: [ web_app, image] }
> exposed_port: { get_property: [ web_app, 
> port] }
> target_host: { get_property: [ database, 
> name] }
> target_port: { get_property: [ database, 
> port] }
> isService: true
>
> All my TOPOLOGY templates have a value, so it's not an issue in my case.
> Only "name" and "image" from my NODE-TYPE have the required definition 
> as "true". So I Must mandatory have these input specified in my 
> NODE-TEMPLATE which I have specified.
> Remaining NODE-TYPE inputs "exposed_port", "target_port", "target_host", "
> labels"  and "isService" have the required definition as "false".  
> Hence I may or may not specify them in my NODE-TEMPLATE input section.
> Except "labels" I have metioned all my optional outputs. I expect my 
> service to be started without any issue but it fails with the error "label"
> is not specified. This is why I find ARIA is having a problem.
>
>
> # python /root/incubator-ariatosca/aria/cli/main.py executions start 
> -s
> demo-sr-1 install
> Required inputs [u'labels'] have not been specified - expected inputs:
> [u'isService', u'name', u'exposed_port', u'image', u'labels', 
> u'target_port', u

RE: Query on operation inputs

[D Jayachandran]

 key "required" is optional in 
YAML, meaning that you do not have to specify it. Its default value is "true". 
So, unless you specify "required: false", that property is required. So 
actually all your "required" true" lines are redundant (informative, but don't 
change functionality).

So, let's look at your "isService" input. At the node type, it is defined as 
required: false. And indeed, if at the node template I don't assign a value to 
it, ARIA has no problem. However, if you do not assign a value to a required 
input, say "image", then ARIA would be unhappy.

I hope this is clear, though I have a feeling you are asking about something 
else which I'm not quite understanding. Again, a shorter and complete example 
would help demonstrate what you mean.


On Thu, May 25, 2017 at 9:56 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Ran,
>
> When I refer the TOSCA spec, it says
>
> " An optional key that declares a property as required (true) or not 
> (false)."
> property_required: represents an optional boolean value (true or 
> false) indicating whether or not the property is required.  If this 
> keyname is not present on a property definition, then the property 
> SHALL be considered required (i.e., true) by default.
>
> It is not clear to whom this property is required or not ?
>
> With your argument, it seems we always need to provide a default value 
> to an input, when we don’t declare in my service template. Is my 
> understanding correct here ?
> But the TOSCA spec says the default value is always an optional one. 
> Also since the parser validates the service template inputs according 
> to the "required" field am not sure why we need another validation 
> during the execution ?
>
> I also don’t find any reference in TOSCA spec which says, all inputs 
> defined in node type be declared in node template to be used by any 
> operation. Could you please help me with that reference in TOSCA spec ?
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Ran Ziv [mailto:r...@gigaspaces.com]
> Sent: Thursday, May 25, 2017 5:16 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Query on operation inputs
>
> Yes, I understand the confusion here. The issue is that, despite its 
> name, the "required" field isn't what defines whether an input is 
> optional or not
> - it is only relevant during the parsing phase (This is according to 
> our understanding of the TOSCA spec. Tal could probably expand more on this).
> What's relevant for deciding whether an input is required or not for 
> actual execution is whether it has a default value - so all inputs 
> would have a value when the actual execution takes place.
>
> I hope this helps clearing this confusing issue..
>
> Ran
>
> On Thu, May 25, 2017 at 2:08 PM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi Ran,
> >
> > Thanks for your response.
> >
> > In my case, I have defined the inputs as optional under the create 
> > operation of my custom node type.
> > Since it is an optional input, I haven't declared it in my node-template.
> > I assume optional input may or may not be declared in a service 
> > template
> ?
> > Am I missing something here ?
> >
> > Please find below the node type and node template in my case.
> >
> > # python /root/incubator-ariatosca/aria/cli/main.py executions start 
> > -s
> > demo-sr-1 install
> > Required inputs [u'labels'] have not been specified - expected inputs:
> > [u'isService', u'name', u'exposed_port', u'image', u'labels', 
> > u'target_port', u'target_host']
> >
> > Node-type
> >
> > node_types:
> > test.nodes.Container.Application:
> > derived_from: tosca.nodes.Root
> > properties:
> > name:
> >   type: string
> >   required: true
> > image:
> >   type: string
> >   required: true
> > port:
> >   type: integer
> >   required: false
> > interfaces:
> > Standard:
> > type: tosca.interfaces.node.lifecycle.Standard
> > create:
> > inputs:
> > name:
> > type: string
> > required: true
> > image:
> > type: string
> > requ

RE: Query related to substitution mapping

[D Jayachandran]

Hi Tal,

Did you get the attachments ?

If not . . please find below templates.

db.yaml

tosca_definitions_version: tosca_simple_yaml_1_0

topology_template:

  substitution_mappings:
#node_type: tosca.nodes.Database
node_type: my.nodes.database
capabilities:
  database_endpoint: [ db_app, database_endpoint ]

  node_templates:

db_app:
  type: tosca.nodes.Database
  properties:
name: sub_map_db
  interfaces:
Standard:
  create:
implementation: test_plugin.test_method
  delete:
implementation: test_plugin.test_method
  requirements:
- host:
node: db_server

db_server:
  type: tosca.nodes.DBMS
  interfaces:
Standard:
  create:
implementation: test_plugin.test_method
  delete:
implementation: test_plugin.test_method
  requirements:
- host:
node: db_host

db_host:
  type: tosca.nodes.Compute
  interfaces:
Standard:
  create:
implementation: test_plugin.test_method
  delete:
implementation: test_plugin.test_method


web.yaml

tosca_definitions_version: tosca_simple_yaml_1_0

imports:
  - ./db.yaml

node_types:
  my.nodes.database:
derived_from: tosca.nodes.Database

topology_template:

  node_templates:

web_app:
  type: tosca.nodes.WebApplication
  interfaces:
Standard:
  create:
implementation: test_plugin.test_method
  delete:
implementation: test_plugin.test_method
  requirements:
- host:
node: web_server
- dependency:
node: database

web_server:
  type: tosca.nodes.WebServer
  interfaces:
Standard:
  create:
implementation: test_plugin.test_method
  delete:
implementation: test_plugin.test_method
  requirements:
- host:
node: web_host

web_host:
  type: tosca.nodes.Compute
  interfaces:
Standard:
  create:
implementation: test_plugin.test_method
  delete:
implementation: test_plugin.test_method

database:
#  type: tosca.nodes.Database
  type: my.nodes.database
  properties:
name: web_db



Regards,
DJ
-Original Message-
From: D Jayachandran 
Sent: Friday, May 26, 2017 2:30 PM
To: dev@ariatosca.incubator.apache.org
Cc: Vaishnavi K.R <vaishnavi@ericsson.com>; S Shenbaga Rajan 
<s.shenbaga.ra...@ericsson.com>
Subject: RE: Query related to substitution mapping

Hi Tal,

Please find the attachment for an example of substitution mapping.
The db.yaml is the substituting template which is imported to web.yaml. 
The web.yaml has an abstract node template "database" which would be 
substituted with db.yaml.

We want to understand is it mandatory to have templates imported for 
substitution to work ? Does TOSCA spec says this ?
The use-case for us would be to have substitution mapping without importing the 
template but to find the template from the already available service-templates 
in the Database.

You could refer Section 2.10  in TOSCA simple yaml 1.0 for more information on 
substitution mapping.

Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@gigaspaces.com]
Sent: Thursday, May 25, 2017 10:32 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Query related to substitution mapping

Hi DJ,

I'm not sure what you mean by "the substituting template". Actually, ARIA does 
almost nothing with substitution templates right now, just parses, validates, 
and stores the info. Indeed, if you refer to a node type there, it should be 
expected that the current template would need to know of that type, possibly by 
importing.

Could you provide a short example to clarify?

On Thu, May 25, 2017 at 5:32 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> The substitution mapping works in the latest APACHE ARIA code only if 
> the substituting template is imported in the top-level template.
>
> This seems to be contradicting with the TOSCA specification where the 
> substitution is expected to happen without the import (though not 
> explicitly mentioned).
>
> We are looking at the possible ways to identify the appropriate node 
> template without importing the substituting template. ( Possibly by 
> going through already available service models for a substitutable 
> entity )
>
> Do you have any plans to have substitution mapping work without having 
> the template imported every time ?
> Do you have any feedback on this and if our understanding is correct ?
>
>
> Regards,
> DJ
>
>
>
>


--
Tal Liron
Senior Engineer
t...@gigaspaces.com | +1 (773) 828-9339
Cloudify | http://getcloudify.org
<http://getcloudify.org?utm_source=sign

RE: Query related to substitution mapping

[D Jayachandran]

Hi Tal,

Please find the attachment for an example of substitution mapping.
The db.yaml is the substituting template which is imported to web.yaml. 
The web.yaml has an abstract node template "database" which would be 
substituted with db.yaml.

We want to understand is it mandatory to have templates imported for 
substitution to work ? Does TOSCA spec says this ?
The use-case for us would be to have substitution mapping without importing the 
template but to find the template from the already available service-templates 
in the Database.

You could refer Section 2.10  in TOSCA simple yaml 1.0 for more information on 
substitution mapping.

Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@gigaspaces.com] 
Sent: Thursday, May 25, 2017 10:32 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Query related to substitution mapping

Hi DJ,

I'm not sure what you mean by "the substituting template". Actually, ARIA does 
almost nothing with substitution templates right now, just parses, validates, 
and stores the info. Indeed, if you refer to a node type there, it should be 
expected that the current template would need to know of that type, possibly by 
importing.

Could you provide a short example to clarify?

On Thu, May 25, 2017 at 5:32 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> The substitution mapping works in the latest APACHE ARIA code only if 
> the substituting template is imported in the top-level template.
>
> This seems to be contradicting with the TOSCA specification where the 
> substitution is expected to happen without the import (though not 
> explicitly mentioned).
>
> We are looking at the possible ways to identify the appropriate node 
> template without importing the substituting template. ( Possibly by 
> going through already available service models for a substitutable 
> entity )
>
> Do you have any plans to have substitution mapping work without having 
> the template imported every time ?
> Do you have any feedback on this and if our understanding is correct ?
>
>
> Regards,
> DJ
>
>
>
>


--
Tal Liron
Senior Engineer
t...@gigaspaces.com | +1 (773) 828-9339
Cloudify | http://getcloudify.org
<http://getcloudify.org?utm_source=signaturesatori_medium=email_campaign=general_signature>

<https://twitter.com/CloudifySource>
<https://www.linkedin.com/groups/8467478>
<https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
[image: Azure Webinar]
<http://getcloudify.org/webinars/Azure-plugin-for-cloudify-webinar.html?utm_source=signaturesatori_medium=email_campaign=general_signature>

RE: Query on operation inputs

[D Jayachandran]

Hi Ran,

When I refer the TOSCA spec, it says 

" An optional key that declares a property as required (true) or not (false)."
property_required: represents an optional boolean value (true or false) 
indicating whether or not the property is required.  If this keyname is not 
present on a property definition, then the property SHALL be considered 
required (i.e., true) by default.

It is not clear to whom this property is required or not ? 

With your argument, it seems we always need to provide a default value to an 
input, when we don’t declare in my service template. Is my understanding 
correct here ?
But the TOSCA spec says the default value is always an optional one. Also since 
the parser validates the service template inputs according to the "required" 
field am not sure why we need another validation during the execution ?

I also don’t find any reference in TOSCA spec which says, all inputs defined in 
node type be declared in node template to be used by any operation. Could you 
please help me with that reference in TOSCA spec ?


Regards,
DJ

-Original Message-
From: Ran Ziv [mailto:r...@gigaspaces.com] 
Sent: Thursday, May 25, 2017 5:16 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Query on operation inputs

Yes, I understand the confusion here. The issue is that, despite its name, the 
"required" field isn't what defines whether an input is optional or not
- it is only relevant during the parsing phase (This is according to our 
understanding of the TOSCA spec. Tal could probably expand more on this).
What's relevant for deciding whether an input is required or not for actual 
execution is whether it has a default value - so all inputs would have a value 
when the actual execution takes place.

I hope this helps clearing this confusing issue..

Ran

On Thu, May 25, 2017 at 2:08 PM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Ran,
>
> Thanks for your response.
>
> In my case, I have defined the inputs as optional under the create 
> operation of my custom node type.
> Since it is an optional input, I haven't declared it in my node-template.
> I assume optional input may or may not be declared in a service template ?
> Am I missing something here ?
>
> Please find below the node type and node template in my case.
>
> # python /root/incubator-ariatosca/aria/cli/main.py executions start 
> -s
> demo-sr-1 install
> Required inputs [u'labels'] have not been specified - expected inputs:
> [u'isService', u'name', u'exposed_port', u'image', u'labels', 
> u'target_port', u'target_host']
>
> Node-type
>
> node_types:
> test.nodes.Container.Application:
> derived_from: tosca.nodes.Root
> properties:
> name:
>   type: string
>   required: true
> image:
>   type: string
>   required: true
> port:
>   type: integer
>   required: false
> interfaces:
> Standard:
> type: tosca.interfaces.node.lifecycle.Standard
> create:
> inputs:
> name:
> type: string
> required: true
> image:
> type: string
> required: true
> exposed_port:
> type: integer
> required: false
> target_port:
> type: integer
> required: false
> target_host:
> type: integer
> required: false
> labels:
> type: string
> required: false
> isService:
> type: boolean
> required: false
> implementation:
> primary: sample > sample.samplemethod
>
> Node template:
>
> web_app:
> type: test.nodes.Container.Application
> properties:
> name: { get_input: web_app_name }
> image: { get_input: web_app_image }
> port: { get_input: web_app_port }
> requirements:
> - dependency:
>   node: database
>   relationship:
>   type: tosca.relationships.DependsOn
> interfaces:
> Standard

RE: Query on operation inputs

[D Jayachandran]

Hi Ran,

Thanks for your response.

In my case, I have defined the inputs as optional under the create operation of 
my custom node type.
Since it is an optional input, I haven't declared it in my node-template. I 
assume optional input may or may not be declared in a service template ?
Am I missing something here ?

Please find below the node type and node template in my case.

# python /root/incubator-ariatosca/aria/cli/main.py executions start -s 
demo-sr-1 install
Required inputs [u'labels'] have not been specified - expected inputs: 
[u'isService', u'name', u'exposed_port', u'image', u'labels', u'target_port', 
u'target_host']

Node-type

node_types:
test.nodes.Container.Application:
derived_from: tosca.nodes.Root
properties:
name:
  type: string
  required: true
image:
  type: string
  required: true
port:
  type: integer
  required: false
interfaces:
Standard:
type: tosca.interfaces.node.lifecycle.Standard
create:
inputs:
name:
type: string
required: true
image:
type: string
required: true
exposed_port:
type: integer
required: false
target_port:
type: integer
required: false
target_host:
type: integer
required: false
labels:
type: string
required: false
isService:
type: boolean
required: false
implementation:
primary: sample > sample.samplemethod

Node template:

web_app:
type: test.nodes.Container.Application
properties:
name: { get_input: web_app_name }
image: { get_input: web_app_image }
port: { get_input: web_app_port }
requirements:
- dependency:
  node: database
  relationship:
  type: tosca.relationships.DependsOn
interfaces:
Standard:
 create:
inputs:
name: { get_input: web_app_name }
image: { get_property: [ web_app, image] }
exposed_port: { get_property: [ web_app, port] }
target_host: { get_property: [ database, name] }
target_port: { get_property: [ database, port] }
isService: true

Regards,
DJ

-Original Message-
From: Ran Ziv [mailto:r...@gigaspaces.com] 
Sent: Thursday, May 25, 2017 4:07 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Query on operation inputs

Hi,

Weird, I remember responding to this mail before, but it doesn't seem like I 
have.
In any case, it is indeed our intention that no inputs may be passed into 
operations unless they have been clearly declared in the service-template.
ARIA opts to be a strict implementation of TOSCA wherever possible.

Ran

On Thu, May 25, 2017 at 1:22 PM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> The latest Apache-aria is throwing a validation error during the 
> execution of a service.
> It demands all the operation inputs defined in a node type be declared 
> in the service template though they are optional inputs.
> Could you please let us know if this change was intentional ?
>
>
> Regards,
> DJ(D Jayachandran)
>

Query related to substitution mapping

[D Jayachandran]

Hi,

The substitution mapping works in the latest APACHE ARIA code only if the 
substituting template is imported in the top-level template.

This seems to be contradicting with the TOSCA specification where the 
substitution is expected to happen without the import (though not explicitly 
mentioned).

We are looking at the possible ways to identify the appropriate node template 
without importing the substituting template. ( Possibly by going through 
already available service models for a substitutable entity )

Do you have any plans to have substitution mapping work without having the 
template imported every time ?
Do you have any feedback on this and if our understanding is correct ?


Regards,
DJ

RE: Query on operation inputs

[D Jayachandran]

Hi,

The latest Apache-aria is throwing a validation error during the execution of a 
service.
It demands all the operation inputs defined in a node type be declared in the 
service template though they are optional inputs.
Could you please let us know if this change was intentional ?


Regards,
DJ(D Jayachandran)

RE: Query on operation inputs

[D Jayachandran]

Hi,

The latest Apache-aria is throwing a validation error during the execution of a 
service.
It demands all the operation inputs defined in a node type be declared in the 
service template though they are optional inputs.
Could you please let us know if this change was intentional ?


Regards,
DJ(D Jayachandran)