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