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 <[email protected]> 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 < > [email protected]> wrote: > >> Hi Tal, >> >> Have you got a chance to look into this below issue ? >> >> Regards, >> DJ >> -----Original Message----- >> From: D Jayachandran [mailto:[email protected]] >> Sent: Monday, June 05, 2017 3:44 PM >> To: [email protected] >> 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:[email protected]] >> Sent: Thursday, June 01, 2017 9:59 PM >> To: [email protected] >> 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 <[email protected]> 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 < >> > [email protected]> >> > 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:[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-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: [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-configura >> > > > tion 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> >> > > > > > >> > > > > >> > > > >> > > >> > >> >> >> >> -- >> Tal Liron >> Senior Engineer >> [email protected] | +1 (773) 828-9339 >> Cloudify | http://getcloudify.org >> <http://getcloudify.org?utm_source=signaturesatori&utm_mediu >> m=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 Solutions Architect <http://cloudify.co> > ------------------------------ > M: +1-312-375-8299 http://cloudify.co @cloudifysource > <https://twitter.com/CloudifySource> > <https://www.linkedin.com/company-beta/17918192/> > <https://github.com/cloudify-cosmo> > <https://www.youtube.com/cloudifysource> > > -- Tal Liron, Senior Solutions Architect <http://cloudify.co> ------------------------------ M: +1-312-375-8299 http://cloudify.co @cloudifysource <https://twitter.com/CloudifySource> <https://www.linkedin.com/company-beta/17918192/> <https://github.com/cloudify-cosmo> <https://www.youtube.com/cloudifysource>
