ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ran Ziv <...@gigaspaces.com>
Subject Re: Query on operation inputs
Date Thu, 01 Jun 2017 12:10:05 GMT
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.jayachandran@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:ran@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.jayachandran@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:ran@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.jayachandran@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:ran@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 <tal@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.jayachandran@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:tal@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.jayachandran@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:ran@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.jayachandran@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:ran@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.jayachandran@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)
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Tal Liron
> > > > > Senior Engineer
> > > > > tal@gigaspaces.com | +1 (773) 828-9339 Cloudify |
> > > > > http://getcloudify.org
> > > > > <http://getcloudify.org?utm_source=signaturesatori&utm_
> > > > > medium=email&utm_campaign=general_signature>
> > > > >
> > > > > <https://twitter.com/CloudifySource>
> > > > > <https://www.linkedin.com/groups/8467478>
> > > > > <https://github.com/cloudify-cosmo>   <
> https://github.com/cloudify-
> > > cosmo
> > > > >
> > > > > [image: Azure Webinar]
> > > > > <http://getcloudify.org/webinars/Azure-plugin-for-
> > > > > cloudify-webinar.html?utm_source=signaturesatori&utm_
> > > > > medium=email&utm_campaign=general_signature>
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Tal Liron
> > > > Senior Engineer
> > > > tal@gigaspaces.com | +1 (773) 828-9339 Cloudify |
> > > > http://getcloudify.org
> > > > <http://getcloudify.org?utm_source=signaturesatori&utm_
> > > > medium=email&utm_campaign=general_signature>
> > > >
> > > > <https://twitter.com/CloudifySource>
> > > > <https://www.linkedin.com/groups/8467478>
> > > > <https://github.com/cloudify-cosmo>   <https://github.com/cloudify-
> > cosmo
> > > >
> > > > [image: Azure Webinar]
> > > > <http://getcloudify.org/webinars/Azure-plugin-for-
> > > > cloudify-webinar.html?utm_source=signaturesatori&utm_
> > > > medium=email&utm_campaign=general_signature>
> > > >
> > >
> >
>

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