Re: Query on operation inputs

[Avia Efrat]

Quick update on this issue:
We merged the relevant pull request:
https://github.com/apache/incubator-ariatosca/pull/187
Now inputs behave as expected.


On Tue, Jul 11, 2017 at 5:39 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Avia,
>
> Thanks for the detailed explanation. Finally we have better clarity and
> are in the same page.
>
> Regards,
> DJ
>
> -Original Message-
> From: Avia Efrat [mailto:a...@gigaspaces.com]
> Sent: Tuesday, July 11, 2017 3:42 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Query on operation inputs
>
> Here is the Jira issue:
> https://issues.apache.org/jira/browse/ARIA-313
>
> On Tue, Jul 11, 2017 at 12:44 AM, Ran Ziv <r...@gigaspaces.com> wrote:
>
> > Avia, could you please create a JIRA issue for this?
> >
> >
> > On Mon, Jul 10, 2017 at 5:12 PM, Avia Efrat <a...@gigaspaces.com> wrote:
> >
> > > Hello DJ,
> > >
> > > I ran the example you provided: https://github.com/djay8887/Ar
> > > ia-operationInputs [It should be noted that you can't just parse the
> > > service template kubernetes-deployment.yaml as is. I needed to
> > > create a folder named type and place kubernetes_type.yaml in there,
> > > as the import: section in your service templates contains `-
> > > *types*/kubernetes_type.yaml`]
> > >
> > > *Short answer:*
> > > You are correct, the example should pass, and we will change the
> > > code accordingly.
> > >
> > > *Longer answer + explanations:*
> > > I will separate my answer into three parts. I will repeat some of
> > > what
> > was
> > > said before me, but I think it will help clear the situation.
> > > 1. The result of my run.
> > > 2. Why do we currently get this error.
> > > 3. Our revised understanding of the TOSCA spec regarding the
> > > required
> > field
> > > of node type operation inputs.
> > >
> > > *1.* *The result of my run:*
> > > The commands I ran were:
> > > aria plugins install sample-1.0.0-py27-none-any.wgn aria
> > > service-templates store kubernetes-deployment.yaml dj aria services
> > > create -t dj dj aria executions start -s dj install after running
> > > the last command I got:
> > > Declared parameters "labels" have not been provided values
> > >
> > > *2.* *Why do we currently get this error:* First, let my just
> > > clarify, that this error has no relation whatsoever to the contents
> > > of the inputs section under topology_template.
> > > We are dealing here only with the inputs section of an operation,
> > > which
> > is
> > > section 3.5.13 Operation Definition <https://goo.gl/g5bMtV>.
> > > Currently, when we execute a workflow (aria executions start ...),
> > > we
> > check
> > > the inputs of each operation in the following manner (ignoring
> > > interface inputs for now):
> > > we check that every input defined in the input section of the node
> > template
> > > operation, whether the input is required or not has a value, has a
> value.
> > > This check is done in the merge_parameters_value function, inside
> > > aria/modelling/utils, so you can check the logic yourself.
> > >
> > > Anyway, these values can be supplied directly from the service
> > > template,
> > or
> > > in an indirect way via execution inputs, or programmatically when
> > creating
> > > workflow tasks. The latter method shouldn't concern us now, as we
> > > are dealing with the operation inputs that were provided in the
> > > inputs
> > section
> > > of the operation.
> > >
> > > So, in conclusion, we get this error since the labels input is not
> > assigned
> > > a value in the inputs section of the operation inside the node
> template.
> > > This happens even if the input is defined as required: false in the
> > inputs
> > > section of the operation inside the node *type*.
> > >
> > > *3. **Our revised understanding of the TOSCA spec regarding the
> > > required field operation definition inputs:* After rechecking the
> > > spec, we feel that an operation input that has
> > > required:
> > > false  indeed allows it not to be defined in the corresponding
> > > operation
> > in
> > > the service template. We base this on section 3.5.13.1 Operation
> > Definition
> > > keyname <https://goo.gl/g5bMtV>. This section clear

RE: Query on operation inputs

[D Jayachandran]

Hi Avia,

Thanks for the detailed explanation. Finally we have better clarity and are in 
the same page.

Regards,
DJ

-Original Message-
From: Avia Efrat [mailto:a...@gigaspaces.com] 
Sent: Tuesday, July 11, 2017 3:42 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Query on operation inputs

Here is the Jira issue:
https://issues.apache.org/jira/browse/ARIA-313

On Tue, Jul 11, 2017 at 12:44 AM, Ran Ziv <r...@gigaspaces.com> wrote:

> Avia, could you please create a JIRA issue for this?
>
>
> On Mon, Jul 10, 2017 at 5:12 PM, Avia Efrat <a...@gigaspaces.com> wrote:
>
> > Hello DJ,
> >
> > I ran the example you provided: https://github.com/djay8887/Ar 
> > ia-operationInputs [It should be noted that you can't just parse the 
> > service template kubernetes-deployment.yaml as is. I needed to 
> > create a folder named type and place kubernetes_type.yaml in there, 
> > as the import: section in your service templates contains `- 
> > *types*/kubernetes_type.yaml`]
> >
> > *Short answer:*
> > You are correct, the example should pass, and we will change the 
> > code accordingly.
> >
> > *Longer answer + explanations:*
> > I will separate my answer into three parts. I will repeat some of 
> > what
> was
> > said before me, but I think it will help clear the situation.
> > 1. The result of my run.
> > 2. Why do we currently get this error.
> > 3. Our revised understanding of the TOSCA spec regarding the 
> > required
> field
> > of node type operation inputs.
> >
> > *1.* *The result of my run:*
> > The commands I ran were:
> > aria plugins install sample-1.0.0-py27-none-any.wgn aria 
> > service-templates store kubernetes-deployment.yaml dj aria services 
> > create -t dj dj aria executions start -s dj install after running 
> > the last command I got:
> > Declared parameters "labels" have not been provided values
> >
> > *2.* *Why do we currently get this error:* First, let my just 
> > clarify, that this error has no relation whatsoever to the contents 
> > of the inputs section under topology_template.
> > We are dealing here only with the inputs section of an operation, 
> > which
> is
> > section 3.5.13 Operation Definition <https://goo.gl/g5bMtV>.
> > Currently, when we execute a workflow (aria executions start ...), 
> > we
> check
> > the inputs of each operation in the following manner (ignoring 
> > interface inputs for now):
> > we check that every input defined in the input section of the node
> template
> > operation, whether the input is required or not has a value, has a value.
> > This check is done in the merge_parameters_value function, inside 
> > aria/modelling/utils, so you can check the logic yourself.
> >
> > Anyway, these values can be supplied directly from the service 
> > template,
> or
> > in an indirect way via execution inputs, or programmatically when
> creating
> > workflow tasks. The latter method shouldn't concern us now, as we 
> > are dealing with the operation inputs that were provided in the 
> > inputs
> section
> > of the operation.
> >
> > So, in conclusion, we get this error since the labels input is not
> assigned
> > a value in the inputs section of the operation inside the node template.
> > This happens even if the input is defined as required: false in the
> inputs
> > section of the operation inside the node *type*.
> >
> > *3. **Our revised understanding of the TOSCA spec regarding the 
> > required field operation definition inputs:* After rechecking the 
> > spec, we feel that an operation input that has
> > required:
> > false  indeed allows it not to be defined in the corresponding 
> > operation
> in
> > the service template. We base this on section 3.5.13.1 Operation
> Definition
> > keyname <https://goo.gl/g5bMtV>. This section clearly state the node
> type
> > operation inputs are of type property definitions (3.5.8)
> > <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#
> > DEFN_ELEMENT_PROPERTY_DEFN>
> > .
> >
> > Therefore, the required field of a node type operation input is the 
> > same
> as
> > the required field in a node type property.
> >
> > So, just as you can omit in a node template property that has required:
> > false in its corresponding node type property, you can omit a node
> template
> > operation input that has required: false in its corresponding node 
> > type operation

Re: Query on operation inputs

[Avia Efrat]

Here is the Jira issue:
https://issues.apache.org/jira/browse/ARIA-313

On Tue, Jul 11, 2017 at 12:44 AM, Ran Ziv <r...@gigaspaces.com> wrote:

> Avia, could you please create a JIRA issue for this?
>
>
> On Mon, Jul 10, 2017 at 5:12 PM, Avia Efrat <a...@gigaspaces.com> wrote:
>
> > Hello DJ,
> >
> > I ran the example you provided: https://github.com/djay8887/Ar
> > ia-operationInputs
> > [It should be noted that you can't just parse the service template
> > kubernetes-deployment.yaml as is. I needed to create a folder named type
> > and place kubernetes_type.yaml in there, as the import: section in your
> > service templates contains `- *types*/kubernetes_type.yaml`]
> >
> > *Short answer:*
> > You are correct, the example should pass, and we will change the code
> > accordingly.
> >
> > *Longer answer + explanations:*
> > I will separate my answer into three parts. I will repeat some of what
> was
> > said before me, but I think it will help clear the situation.
> > 1. The result of my run.
> > 2. Why do we currently get this error.
> > 3. Our revised understanding of the TOSCA spec regarding the required
> field
> > of node type operation inputs.
> >
> > *1.* *The result of my run:*
> > The commands I ran were:
> > aria plugins install sample-1.0.0-py27-none-any.wgn
> > aria service-templates store kubernetes-deployment.yaml dj
> > aria services create -t dj dj
> > aria executions start -s dj install
> > after running the last command I got:
> > Declared parameters "labels" have not been provided values
> >
> > *2.* *Why do we currently get this error:*
> > First, let my just clarify, that this error has no relation whatsoever to
> > the contents of the inputs section under topology_template.
> > We are dealing here only with the inputs section of an operation, which
> is
> > section 3.5.13 Operation Definition <https://goo.gl/g5bMtV>.
> > Currently, when we execute a workflow (aria executions start ...), we
> check
> > the inputs of each operation in the following manner (ignoring interface
> > inputs for now):
> > we check that every input defined in the input section of the node
> template
> > operation, whether the input is required or not has a value, has a value.
> > This check is done in the merge_parameters_value function, inside
> > aria/modelling/utils, so you can check the logic yourself.
> >
> > Anyway, these values can be supplied directly from the service template,
> or
> > in an indirect way via execution inputs, or programmatically when
> creating
> > workflow tasks. The latter method shouldn't concern us now, as we are
> > dealing with the operation inputs that were provided in the inputs
> section
> > of the operation.
> >
> > So, in conclusion, we get this error since the labels input is not
> assigned
> > a value in the inputs section of the operation inside the node template.
> > This happens even if the input is defined as required: false in the
> inputs
> > section of the operation inside the node *type*.
> >
> > *3. **Our revised understanding of the TOSCA spec regarding the required
> > field operation definition inputs:*
> > After rechecking the spec, we feel that an operation input that has
> > required:
> > false  indeed allows it not to be defined in the corresponding operation
> in
> > the service template. We base this on section 3.5.13.1 Operation
> Definition
> > keyname <https://goo.gl/g5bMtV>. This section clearly state the node
> type
> > operation inputs are of type property definitions (3.5.8)
> > <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#
> > DEFN_ELEMENT_PROPERTY_DEFN>
> > .
> >
> > Therefore, the required field of a node type operation input is the same
> as
> > the required field in a node type property.
> >
> > So, just as you can omit in a node template property that has required:
> > false in its corresponding node type property, you can omit a node
> template
> > operation input that has required: false in its corresponding node type
> > operation input.
> >
> >
> >
> >
> > On Mon, Jul 3, 2017 at 10:17 PM, Tal Liron <t...@gigaspaces.com> wrote:
> >
> > > Oops, it seems your email from before was somehow tagged as read by
> > > mistake, so I missed it. I will get to it after the US holiday!
> > >
> > > On Mon, Jul 3, 2017 at 4:21 AM, D Jayachandran <
> > >

Re: Query on operation inputs

[Ran Ziv]

Avia, could you please create a JIRA issue for this?


On Mon, Jul 10, 2017 at 5:12 PM, Avia Efrat <a...@gigaspaces.com> wrote:

> Hello DJ,
>
> I ran the example you provided: https://github.com/djay8887/Ar
> ia-operationInputs
> [It should be noted that you can't just parse the service template
> kubernetes-deployment.yaml as is. I needed to create a folder named type
> and place kubernetes_type.yaml in there, as the import: section in your
> service templates contains `- *types*/kubernetes_type.yaml`]
>
> *Short answer:*
> You are correct, the example should pass, and we will change the code
> accordingly.
>
> *Longer answer + explanations:*
> I will separate my answer into three parts. I will repeat some of what was
> said before me, but I think it will help clear the situation.
> 1. The result of my run.
> 2. Why do we currently get this error.
> 3. Our revised understanding of the TOSCA spec regarding the required field
> of node type operation inputs.
>
> *1.* *The result of my run:*
> The commands I ran were:
> aria plugins install sample-1.0.0-py27-none-any.wgn
> aria service-templates store kubernetes-deployment.yaml dj
> aria services create -t dj dj
> aria executions start -s dj install
> after running the last command I got:
> Declared parameters "labels" have not been provided values
>
> *2.* *Why do we currently get this error:*
> First, let my just clarify, that this error has no relation whatsoever to
> the contents of the inputs section under topology_template.
> We are dealing here only with the inputs section of an operation, which is
> section 3.5.13 Operation Definition <https://goo.gl/g5bMtV>.
> Currently, when we execute a workflow (aria executions start ...), we check
> the inputs of each operation in the following manner (ignoring interface
> inputs for now):
> we check that every input defined in the input section of the node template
> operation, whether the input is required or not has a value, has a value.
> This check is done in the merge_parameters_value function, inside
> aria/modelling/utils, so you can check the logic yourself.
>
> Anyway, these values can be supplied directly from the service template, or
> in an indirect way via execution inputs, or programmatically when creating
> workflow tasks. The latter method shouldn't concern us now, as we are
> dealing with the operation inputs that were provided in the inputs section
> of the operation.
>
> So, in conclusion, we get this error since the labels input is not assigned
> a value in the inputs section of the operation inside the node template.
> This happens even if the input is defined as required: false in the inputs
> section of the operation inside the node *type*.
>
> *3. **Our revised understanding of the TOSCA spec regarding the required
> field operation definition inputs:*
> After rechecking the spec, we feel that an operation input that has
> required:
> false  indeed allows it not to be defined in the corresponding operation in
> the service template. We base this on section 3.5.13.1 Operation Definition
> keyname <https://goo.gl/g5bMtV>. This section clearly state the node type
> operation inputs are of type property definitions (3.5.8)
> <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#
> DEFN_ELEMENT_PROPERTY_DEFN>
> .
>
> Therefore, the required field of a node type operation input is the same as
> the required field in a node type property.
>
> So, just as you can omit in a node template property that has required:
> false in its corresponding node type property, you can omit a node template
> operation input that has required: false in its corresponding node type
> operation input.
>
>
>
>
> On Mon, Jul 3, 2017 at 10:17 PM, Tal Liron <t...@gigaspaces.com> wrote:
>
> > Oops, it seems your email from before was somehow tagged as read by
> > mistake, so I missed it. I will get to it after the US holiday!
> >
> > On Mon, Jul 3, 2017 at 4:21 AM, D Jayachandran <
> > d.jayachand...@ericsson.com>
> > wrote:
> >
> > > Hi Tal,
> > >
> > > Have you got a chance to look into this below issue ?
> > >
> > > Regards,
> > > DJ
> > > -Original Message-
> > > From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> > > Sent: Monday, June 05, 2017 3:44 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: RE: Query on operation inputs
> > >
> > > Hi Tal,
> > >
> > > Please find below the git repo of my example.
> > >
> > > https://github.com/djay8887/Aria-operati

Re: Query on operation inputs

[Avia Efrat]

Hello DJ,

I ran the example you provided: https://github.com/djay8887/Ar
ia-operationInputs
[It should be noted that you can't just parse the service template
kubernetes-deployment.yaml as is. I needed to create a folder named type
and place kubernetes_type.yaml in there, as the import: section in your
service templates contains `- *types*/kubernetes_type.yaml`]

*Short answer:*
You are correct, the example should pass, and we will change the code
accordingly.

*Longer answer + explanations:*
I will separate my answer into three parts. I will repeat some of what was
said before me, but I think it will help clear the situation.
1. The result of my run.
2. Why do we currently get this error.
3. Our revised understanding of the TOSCA spec regarding the required field
of node type operation inputs.

*1.* *The result of my run:*
The commands I ran were:
aria plugins install sample-1.0.0-py27-none-any.wgn
aria service-templates store kubernetes-deployment.yaml dj
aria services create -t dj dj
aria executions start -s dj install
after running the last command I got:
Declared parameters "labels" have not been provided values

*2.* *Why do we currently get this error:*
First, let my just clarify, that this error has no relation whatsoever to
the contents of the inputs section under topology_template.
We are dealing here only with the inputs section of an operation, which is
section 3.5.13 Operation Definition <https://goo.gl/g5bMtV>.
Currently, when we execute a workflow (aria executions start ...), we check
the inputs of each operation in the following manner (ignoring interface
inputs for now):
we check that every input defined in the input section of the node template
operation, whether the input is required or not has a value, has a value.
This check is done in the merge_parameters_value function, inside
aria/modelling/utils, so you can check the logic yourself.

Anyway, these values can be supplied directly from the service template, or
in an indirect way via execution inputs, or programmatically when creating
workflow tasks. The latter method shouldn't concern us now, as we are
dealing with the operation inputs that were provided in the inputs section
of the operation.

So, in conclusion, we get this error since the labels input is not assigned
a value in the inputs section of the operation inside the node template.
This happens even if the input is defined as required: false in the inputs
section of the operation inside the node *type*.

*3. **Our revised understanding of the TOSCA spec regarding the required
field operation definition inputs:*
After rechecking the spec, we feel that an operation input that has required:
false  indeed allows it not to be defined in the corresponding operation in
the service template. We base this on section 3.5.13.1 Operation Definition
keyname <https://goo.gl/g5bMtV>. This section clearly state the node type
operation inputs are of type property definitions (3.5.8)
<http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#DEFN_ELEMENT_PROPERTY_DEFN>
.

Therefore, the required field of a node type operation input is the same as
the required field in a node type property.

So, just as you can omit in a node template property that has required:
false in its corresponding node type property, you can omit a node template
operation input that has required: false in its corresponding node type
operation input.




On Mon, Jul 3, 2017 at 10:17 PM, Tal Liron <t...@gigaspaces.com> wrote:

> Oops, it seems your email from before was somehow tagged as read by
> mistake, so I missed it. I will get to it after the US holiday!
>
> On Mon, Jul 3, 2017 at 4:21 AM, D Jayachandran <
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi Tal,
> >
> > Have you got a chance to look into this below issue ?
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> > Sent: Monday, June 05, 2017 3:44 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: RE: Query on operation inputs
> >
> > 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 sens

Re: Query on operation inputs

[Tal Liron]

DJ, I'm sorry, I'm still not sure what to look at here. The example seems
to run fine.

By the way, you can import ARIA's types (such as aria.Plugin) like so:

imports:
  - aria-1.0

On Mon, Jul 3, 2017 at 2:17 PM, Tal Liron <t...@gigaspaces.com> wrote:

> Oops, it seems your email from before was somehow tagged as read by
> mistake, so I missed it. I will get to it after the US holiday!
>
> On Mon, Jul 3, 2017 at 4:21 AM, D Jayachandran <
> d.jayachand...@ericsson.com> wrote:
>
>> Hi Tal,
>>
>> Have you got a chance to look into this below issue ?
>>
>> Regards,
>> DJ
>> -Original Message-
>> From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
>> Sent: Monday, June 05, 2017 3:44 PM
>> To: dev@ariatosca.incubator.apache.org
>> Subject: RE: Query on operation inputs
>>
>> 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-
>> > > &

Re: Query on operation inputs

[Tal Liron]

Oops, it seems your email from before was somehow tagged as read by
mistake, so I missed it. I will get to it after the US holiday!

On Mon, Jul 3, 2017 at 4:21 AM, D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Hi Tal,
>
> Have you got a chance to look into this below issue ?
>
> Regards,
> DJ
> -Original Message-
> From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> Sent: Monday, June 05, 2017 3:44 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: Query on operation inputs
>
> 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 servic

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 on operation inputs

[Tal Liron]

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

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

[Ran Ziv]

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

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

Re: Query on operation inputs

[Ran Ziv]

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: 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:
> > > typ

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

[Ran Ziv]

t_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'target_host']
> >
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Tal Liron [mailto:t...@gigaspaces.com]
> > Sent: Thursday, May 25, 2017 11:19 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Query on operation inputs
> >
> > Hi DJ, let's try to look at these issues one at a time.
> >
> > I got your YAML to parse OK, but had to change it around a bit... it
> would
> > help if you used a complete example here, and also if it would be much
> > shorter to demonstrate the specific issue you are asking about. There's a
> > lot going on in this example and you are asking a few different
> questions.
> >
> > The error message you are getting is not about operation inputs, but
> about
> > topology template inputs. I can't help much here unless I see those input
> > definitions: they do not appear in your YAML fragment. In general, see
> > section 3.8.2.1 in the TOSCA spec. Values for topology template inputs
> must
> > come from an external source, and indeed in this case you are providing
> > them via the CLI. ARIA makes sure that all required topology template
> > inputs have a value, and that it is a valid value for the type. So,
> that's
> > the error you are seeing.
> >
> > The inputs we *do* see in your YAML fragment are input definitions at the
> > node type and input assignments at the node template. These work
> > differently from topology template inputs, because their values do not
> come
> > from an external source directly (though this can be indirect via
> get_input
> > and other intrinsic functions).
> >
> > According to the spec you quote (3.5.8.2) , the 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 require

Re: Query on operation inputs

[Tal Liron]

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'target_host']
>
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@gigaspaces.com]
> Sent: Thursday, May 25, 2017 11:19 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Query on operation inputs
>
> Hi DJ, let's try to look at thes

RE: Query on operation inputs

[D Jayachandran]

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'target_host']


Regards,
DJ
-Original Message-----
From: Tal Liron [mailto:t...@gigaspaces.com] 
Sent: Thursday, May 25, 2017 11:19 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Query on operation inputs

Hi DJ, let's try to look at these issues one at a time.

I got your YAML to parse OK, but had to change it around a bit... it would help 
if you used a complete example here, and also if it would be much shorter to 
demonstrate the specific issue you are asking about. There's a lot going on in 
this example and you are asking a few different questions.

The error message you are getting is not about operation inputs, but about 
topology template inputs. I can't help much here unless I see those input
definitions: they do not appear in your YAML fragment. In general, see section 
3.8.2.1 in the TOSCA spec. Values for topology template inputs must come from 
an external source, and indeed in this case you are providing them via the CLI. 
ARIA makes sure that all required topology template inputs have a value, and 
that it is a valid value for the type. So, that's the error you are seeing.

The inputs we *do* see in your YAML fragment are input definitions at the node 
type and input assignments at the node template. These work differently from 
topology template inputs, because their values do not come from an external 
source directly (though this can be indirect via get_input and other intrinsic 
functions).

According to the spec you quote (3.5.8.2) , the

Re: Query on operation inputs

[Tal Liron]

Hi DJ, let's try to look at these issues one at a time.

I got your YAML to parse OK, but had to change it around a bit... it would
help if you used a complete example here, and also if it would be much
shorter to demonstrate the specific issue you are asking about. There's a
lot going on in this example and you are asking a few different questions.

The error message you are getting is not about operation inputs, but about
topology template inputs. I can't help much here unless I see those input
definitions: they do not appear in your YAML fragment. In general, see
section 3.8.2.1 in the TOSCA spec. Values for topology template inputs must
come from an external source, and indeed in this case you are providing
them via the CLI. ARIA makes sure that all required topology template
inputs have a value, and that it is a valid value for the type. So, that's
the error you are seeing.

The inputs we *do* see in your YAML fragment are input definitions at the
node type and input assignments at the node template. These work
differently from topology template inputs, because their values do not come
from an external source directly (though this can be indirect via get_input
and other intrinsic functions).

According to the spec you quote (3.5.8.2) , the 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 inpu

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

[Ran Ziv]

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:
>  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)
> >
>

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

Re: Query on operation inputs

[Ran Ziv]

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

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)