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:[email protected]] Sent: Thursday, June 01, 2017 5:24 PM To: [email protected] 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 <[email protected]> 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: [email protected] > 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:[email protected]] > Sent: Thursday, June 01, 2017 2:27 PM > To: [email protected] > 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 < > [email protected] > > 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:[email protected]] > > Sent: Sunday, May 28, 2017 6:14 PM > > To: [email protected] > > 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 <[email protected]> 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 < > > > [email protected] > > > > 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:[email protected]] > > > > Sent: Thursday, May 25, 2017 11:19 PM > > > > To: [email protected] > > > > 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 < > > > > [email protected] > > > > > 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:[email protected]] > > > > > Sent: Thursday, May 25, 2017 5:16 PM > > > > > To: [email protected] > > > > > 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 < > > > > > [email protected] > > > > > > 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:[email protected]] > > > > > > Sent: Thursday, May 25, 2017 4:07 PM > > > > > > To: [email protected] > > > > > > 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 < > > > > > > [email protected] > > > > > > > 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 > > > > [email protected] | +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 > > > [email protected] | +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> > > > > > >
