RE: Query on operation inputs

[D Jayachandran]

Hi Avia,

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

Regards,
DJ

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

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

On Tue, Jul 11, 2017 at 12:44 AM, Ran Ziv  wrote:

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

Re: [VOTE] publish ariatosca 0.1.1

[Suneel Marthi]

+1 binding

1. Checked Sigs and Hashes
2. Verified RAT check


On Mon, Jul 10, 2017 at 1:04 PM, Ran Ziv  wrote:

> This is a vote to release Apache AriaTosca (Incubating) 0.1.1.
> If the vote passes, another vote for approving the release will take place
> on the Apache Incubator's PMC.
>
>
> I created a tarball candidate for the 0.1.1 release and placed it in ARIA's
> /dist/dev folder:
> *https://dist.apache.org/repos/dist/dev/incubator/
> ariatosca/0.1.1-incubating/
>  ariatosca/0.1.1-incubating/>*
>
> The directory contains three packages:
> source - The canonical Apache release - a snapshot of the repository.
> sdist - The pythonic source distribution - contains generated docs,
> examples, and files needed for install from source (yet doesn't contain
> tests etc.).
> bdist - The pythonic binary distribution - contains compiled code.
>
>
> The sdist and bdist packages have been uploaded to test-PyPI:
> https://test.pypi.org/project/apache-ariatosca/0.1.1/
>
>
> The list of issues Resolved for this release can be found in the CHANGELOG
> or here:
>  1=project%3Dariatosca%20and%20status%20in%20(resolved%2C%20closed)>
> https://issues.apache.org/jira/browse/ARIA-312?filter=-
> 1=project%3Dariatosca%20and%20status%20in%20(
> resolved%2C%20closed)%20and%20fixVersion%3D0.1.1
>
>
> Instructions for installation etc. may be found in the README file inside
> the tarball.
> (Please note that the relevant installation instructions are for "source
> installation", not "install from PyPI")
>
>
> To use RAT to validate package conformance with ASF standards, please use
> the ".rat-excludes" file, for example:
> java -jar ../apache-rat-0.12/apache-rat-0.12.jar . -E .rat-excludes
>
>
>
> The vote will last 72 hours.
>
> Please vote:
>
> [ ] +1: Good to go!
> [ ] 0: I don't care
> [ ] -1: Don't release this because...
>
>
> Thanks,
> Ran
>

Re: Inputs to a life cycle operation

[Ran Ziv]

The issue was indeed merged a few days ago.
Note however that it's not a part of the 0.1.0 release (nor will it be a
part of the 0.1.1 one, as it wasn't categorized as a bug fix but as a new
feature). It will be a part of a future 0.2.0 release.

On Mon, Jul 3, 2017 at 1:39 PM, Ran Ziv  wrote:

> Hi DJ,
>
> You're definitely correct - this issue is in fact already in a pull
> request , and
> will hopefully be merged soon.
>
>
> Ran
>
> On Mon, Jul 3, 2017 at 1:04 PM, D Jayachandran <
> d.jayachand...@ericsson.com> wrote:
>
>> Hi,
>>
>> With the current ARIA implementation,
>>
>>
>>   *   Only the operation level inputs, (inputs under
>> "create","configure","start","stop") are passed during a workflow
>> execution.
>>   *   As per TOSCA spec Interface level inputs ( inputs under
>> "Standard" Interface) can also be defined
>>
>> With the above points, don't the interface level inputs also be passed
>> for any operation Task ?
>> I think interface level inputs needs to be merged with operation level
>> but the operation level inputs taking precedence.
>> Please let us know if the above understanding is correct and could be
>> fixed in ARIA ?
>>
>> Regards,
>> DJ
>>
>
>

Re: Query on operation inputs

[Avia Efrat]

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

On Tue, Jul 11, 2017 at 12:44 AM, Ran Ziv  wrote:

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

Re: Installation issue in 0.1.0 release

[Ran Ziv]

I created a new voting thread for a 0.1.1 release candidate.

I understand it's important someone else does the release manager's role as
well, but since this is a quick fix version I hope it's ok I took it again
upon myself.
We'll make sure next time someone else takes this role.


On Mon, Jul 10, 2017 at 4:28 PM, Suneel Marthi  wrote:

> ...and that's something i follow even on the TLPs I am involved with - more
> frequent releases
>
> On Mon, Jul 10, 2017 at 8:54 AM, John D. Ament 
> wrote:
>
> > IMHO, podlings should try to cut releases frequently.  Gets in the habit
> of
> > how to do it.  So if you or someone else has the cycles to cut the
> release
> > I say do it.
> >
> > I personally don't care what version it is, its just a number.
> >
> > John
> >
> > On Mon, Jul 10, 2017 at 8:13 AM Ran Ziv  wrote:
> >
> > > I've found the following issue with the 0.1.0 release:
> > > https://issues.apache.org/jira/browse/ARIA-304
> > >
> > > A fix for this has already been merged into master; PR can be seen
> here:
> > > https://github.com/apache/incubator-ariatosca/pull/178
> > >
> > >
> > >
> > > I'm proposing the possibility of creating a quick 0.1.1 release for
> > fixing
> > > this bug.
> > > On one hand it's not necessarily in the main path (requires optional
> > > dependency installation, not relevant for Windows) and has a simple
> > > workaround (see comment on the JIRA issue); On the other hand, it's a
> > > pretty annoying bug that could deter users from using the 0.1.0, and
> the
> > > fix is simple.
> > >
> > >
> > > If we're to release a 0.1.1 package, there are a few other bug fixes
> that
> > > have been merged since the original 0.1.0 proposal, that we could have
> > as a
> > > part of this release as well:
> > > https://issues.apache.org/jira/browse/ARIA-296
> > > https://issues.apache.org/jira/browse/ARIA-202
> > > https://issues.apache.org/jira/browse/ARIA-298
> > > https://issues.apache.org/jira/browse/ARIA-287
> > >
> > >
> > > What do you think?
> > >
> > > Ran
> > >
> >
>

Re: Query on operation inputs

[Ran Ziv]

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


On Mon, Jul 10, 2017 at 5:12 PM, Avia Efrat  wrote:

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

Re: create_template

[DeWayne Filppi]

By the way, that was the problem.  Thanks.

On Jul 8, 2017 11:51 PM, "Ran Ziv"  wrote:

> In this case, I assume the problem is you haven't loaded the ARIA
> extensions - by which I mean calling this function:
> https://github.com/apache/incubator-ariatosca/blob/0.1.0/
> aria/__init__.py#L54
>
> The above function searches for extensions and loads them.
> The TOSCA parser is loaded as an extension using the extension mechanism,
> so if that function doesn't get called, the TOSCA presenter class won't
> register on here:
> https://github.com/apache/incubator-ariatosca/blob/0.1.0/
> aria/extension.py#L95
>
> In the CLI, for example, it is called here:
> https://github.com/apache/incubator-ariatosca/blob/0.1.0/
> aria/cli/main.py#L59
>
>
> Hope this helps.
>
>
>
> On Sun, Jul 9, 2017 at 7:40 AM, DeWayne Filppi 
> wrote:
>
> > Maybe not.  I installed using "pip install ." in the source root.  I
> didn't
> > use '-e'. I see no extensions module in my venv.  The pth file wasn't
> > present when I used 'pip install .', so I switch to the makefile.  This
> > completed and appeared to put everything in it's right place, but the
> error
> > is unchanged.  To be specific I see:
> >
> > Validation issues:
> >   0: presenter not found
> >  PresenterNotFoundError: presenter not found
> >
> >
> > On Sat, Jul 8, 2017 at 2:27 AM, Ran Ziv  wrote:
> >
> > > Hi DeWayne,
> > >
> > > The error probably means that the ARIA TOSCA extension isn't properly
> > > installed, and therefore the parser can't find a valid reader.
> > > The error message could probably have been somewhat clearer.. Feel free
> > to
> > > create a JIRA issue over this (or I'll create one if you don't :)).
> > >
> > > Note that the ARIA TOSCA extension gets installed when running "pip
> > > install" over the apache-ariatosca project as expected - but when
> > > installing in editable mode, a bug in setuptools causes only the main
> > > ("aria") package to get installed properly instead.
> > > See this JIRA issue: https://issues.apache.org/jira/browse/ARIA-110 -
> > > which
> > > also describes the workaround.
> > > (This is also documented on our Confluence)
> > >
> > > Finally, you can run "make install-virtual" to install inside a Python
> > > virtualenv, and that will also take care of making the mentioned
> > workaround
> > > for you, resulting in a proper installation of the TOSCA extension.
> > > ( See make target here:
> > > https://github.com/apache/incubator-ariatosca/blob/master/Makefile#L38
> )
> > >
> > >
> > > Ran
> > >
> > >
> > > On Sat, Jul 8, 2017 at 7:10 AM, DeWayne Filppi  >
> > > wrote:
> > >
> > > > I'm getting a validation error out of core.create_service_template,
> but
> > > it
> > > > complains about there being no presenter, so I can't figure out what
> > the
> > > > error is (no details are dumped).  The code essentially copies the
> CLI
> > > > code:
> > > >
> > > >
> > > >   service_template_path = service_template_utils.get(
> > > > service_template_path,
> > > >
> > > >  service_template_filename)
> > > >   core = Core(model_storage, resource_storage, plugin_manager)
> > > >   try:
> > > > core.create_service_template(service_template_path,
> > > >  os.path.dirname(service_
> > template_path),
> > > >  template_name)
> > > >
> > >
> >
> >
> >
> > --
> > DeWayne Filppi, Director, Solutions Architect 
> > --
> > M: +17145121706 http://cloudify.co @dfilppi
> > 
> > 
> > 
> > 
> >
>

[VOTE] publish ariatosca 0.1.1

[Ran Ziv]

This is a vote to release Apache AriaTosca (Incubating) 0.1.1.
If the vote passes, another vote for approving the release will take place
on the Apache Incubator's PMC.


I created a tarball candidate for the 0.1.1 release and placed it in ARIA's
/dist/dev folder:
*https://dist.apache.org/repos/dist/dev/incubator/ariatosca/0.1.1-incubating/
*

The directory contains three packages:
source - The canonical Apache release - a snapshot of the repository.
sdist - The pythonic source distribution - contains generated docs,
examples, and files needed for install from source (yet doesn't contain
tests etc.).
bdist - The pythonic binary distribution - contains compiled code.


The sdist and bdist packages have been uploaded to test-PyPI:
https://test.pypi.org/project/apache-ariatosca/0.1.1/


The list of issues Resolved for this release can be found in the CHANGELOG
or here:

https://issues.apache.org/jira/browse/ARIA-312?filter=-1=project%3Dariatosca%20and%20status%20in%20(resolved%2C%20closed)%20and%20fixVersion%3D0.1.1


Instructions for installation etc. may be found in the README file inside
the tarball.
(Please note that the relevant installation instructions are for "source
installation", not "install from PyPI")


To use RAT to validate package conformance with ASF standards, please use
the ".rat-excludes" file, for example:
java -jar ../apache-rat-0.12/apache-rat-0.12.jar . -E .rat-excludes



The vote will last 72 hours.

Please vote:

[ ] +1: Good to go!
[ ] 0: I don't care
[ ] -1: Don't release this because...


Thanks,
Ran

Re: Query on operation inputs

[Avia Efrat]

Hello DJ,

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

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

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

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

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

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

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

*3. **Our revised understanding of the TOSCA spec regarding the required
field operation definition inputs:*
After rechecking the spec, we feel that an operation input that has required:
false  indeed allows it not to be defined in the corresponding operation in
the service template. We base this on section 3.5.13.1 Operation Definition
keyname . This section clearly state the node type
operation inputs are of type property definitions (3.5.8)

.

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

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




On Mon, Jul 3, 2017 at 10:17 PM, Tal Liron  wrote:

> Oops, it seems your email from before was somehow tagged as read by
> mistake, so I missed it. I will get to it after the US holiday!
>
> On Mon, Jul 3, 2017 at 4:21 AM, D Jayachandran <
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi Tal,
> >
> > Have you got a chance to look into this below issue ?
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> > Sent: Monday, June 05, 2017 3:44 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: RE: Query on operation inputs
> >
> > Hi Tal,
> >
> > Please find below the git repo of my example.
> >
> > https://github.com/djay8887/Aria-operationInputs
> >
> > regards,
> > DJ
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@gigaspaces.com]
> > Sent: Thursday, June 01, 2017 9:59 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Query on operation inputs
> >
> > I'm still a bit confused by all this. DJ, could you possibly create a
> > quick git repo with your complete example to make sure we're all on the
> > same page here?
> >
> > On Thu, Jun 1, 2017 at 7:10 AM, Ran Ziv  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 

Re: [VOTE] Add an 'entry-level' label to some of our Jira issues

[Ran Ziv]

"Simple" sounds good (and simple :))

Re providing links to the TOSCA theoretical overview, this is one more
website task we need to do.
I added it to the JIRA issue here:
https://issues.apache.org/jira/browse/ARIA-309




On Mon, Jul 10, 2017 at 3:58 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:

> Hi
> Do you intend to introduce "other levels" or just one label for beginners?
> If you only need one level, then maybe it is best to call it "simple" or
> 'basic"?
>
> Hi Avia and Tal,
> Is it possible to store the quick introduction to TOSCA and theoretical
> overview for everyone to see?
> Thanks
>
> Steve B
>
>
>
>
> -Original Message-
> From: Ran Ziv [mailto:r...@gigaspaces.com]
> Sent: Monday, July 10, 2017 4:39 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: [VOTE] Add an 'entry-level' label to some of our Jira issues
>
> I'm all for it, though I don't really like "entry-level" for the name of
> the label :) Any other suggestions?
>
>
> On Mon, Jul 10, 2017 at 5:09 AM, John D. Ament 
> wrote:
>
> > I think it's a good idea.  Lots of other projects do something
> > similar.  We could link to a query with this from the proposed
> > contributing guide I emailed about earlier.  If we put the
> > contributing guide on confluence, I believe we can even embed a report.
> >
> > John
> >
> > On Sun, Jul 9, 2017 at 9:34 PM Avia Efrat  wrote:
> >
> > > Today Tal (t...@gigaspaces.com) and myself had a very long and
> > > productive face-to-face session with some AT developers about
> > > ARIA. We did a quick introduction to TOSCA (as some of them where
> > > already familiar with it), followed by an theoretical overview and
> live demo of ARIA 0.1.0.
> > >
> > > Some of the AT guys were very interested in contributing to ARIA,
> > > and raised what I think is a very good suggestion. They said that
> > > since sometimes you don't know where to start when contributing to a
> > > large and unfamiliar project, and since some of them or only novice
> > > python programmers, it would very good for them to have Jiras marked
> > > with a special label, such as 'entry-level', to signal that these
> > > Jiras are suitable for beginners.
> > >
> > > So first, I would like to hear your opinions on this suggestion, and
> > > second, if you support it, maybe you have some better input on the
> > > name
> > of
> > > such a label, as I'm not sure I'm pleased with 'entry-level'. (Some
> > > other suggestions were 'first-time-contributor' and 'trivial', but
> > > feel free to suggest your own)
> > >
> > > --
> > > Avia Efrat
> > > SW Engineer
> > > a...@gigaspaces.com | +972546204553 <+972%2054-620-4553> Cloudify |
> > > http://getcloudify.org <
> > > http://getcloudify.org?utm_source=signaturesatori_
> > medium=email_campaign=general_signature
> > > >
> > >
> > > 
> > > 
> > >     cosmo
> > >
> > > [image: Azure Webinar]
> > > <
> > > http://getcloudify.org/webinars/Azure-plugin-for-
> > cloudify-webinar.html?utm_source=signaturesatori_
> > medium=email_campaign=general_signature
> > > >
> > >
> >
>

Re: Installation issue in 0.1.0 release

[Suneel Marthi]

...and that's something i follow even on the TLPs I am involved with - more
frequent releases

On Mon, Jul 10, 2017 at 8:54 AM, John D. Ament 
wrote:

> IMHO, podlings should try to cut releases frequently.  Gets in the habit of
> how to do it.  So if you or someone else has the cycles to cut the release
> I say do it.
>
> I personally don't care what version it is, its just a number.
>
> John
>
> On Mon, Jul 10, 2017 at 8:13 AM Ran Ziv  wrote:
>
> > I've found the following issue with the 0.1.0 release:
> > https://issues.apache.org/jira/browse/ARIA-304
> >
> > A fix for this has already been merged into master; PR can be seen here:
> > https://github.com/apache/incubator-ariatosca/pull/178
> >
> >
> >
> > I'm proposing the possibility of creating a quick 0.1.1 release for
> fixing
> > this bug.
> > On one hand it's not necessarily in the main path (requires optional
> > dependency installation, not relevant for Windows) and has a simple
> > workaround (see comment on the JIRA issue); On the other hand, it's a
> > pretty annoying bug that could deter users from using the 0.1.0, and the
> > fix is simple.
> >
> >
> > If we're to release a 0.1.1 package, there are a few other bug fixes that
> > have been merged since the original 0.1.0 proposal, that we could have
> as a
> > part of this release as well:
> > https://issues.apache.org/jira/browse/ARIA-296
> > https://issues.apache.org/jira/browse/ARIA-202
> > https://issues.apache.org/jira/browse/ARIA-298
> > https://issues.apache.org/jira/browse/ARIA-287
> >
> >
> > What do you think?
> >
> > Ran
> >
>

Re: [VOTE] Add an 'entry-level' label to some of our Jira issues

[Avia Efrat]

These presentationa are not stand-alone, as they consist of bulletins that
were more broadly explained in the session. That being said, there is an 4
hour video and Q session by Tal about TOSCA. We intend to upload it to
the ARIA site soon.
In addition, we are planning to expand our documentation, specifically
about such concepts as custom workflows and plugins.

On Mon, Jul 10, 2017 at 3:58 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:

> Hi
> Do you intend to introduce "other levels" or just one label for beginners?
> If you only need one level, then maybe it is best to call it "simple" or
> 'basic"?
>
> Hi Avia and Tal,
> Is it possible to store the quick introduction to TOSCA and theoretical
> overview for everyone to see?
> Thanks
>
> Steve B
>
>
>
>
> -Original Message-
> From: Ran Ziv [mailto:r...@gigaspaces.com]
> Sent: Monday, July 10, 2017 4:39 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: [VOTE] Add an 'entry-level' label to some of our Jira issues
>
> I'm all for it, though I don't really like "entry-level" for the name of
> the label :) Any other suggestions?
>
>
> On Mon, Jul 10, 2017 at 5:09 AM, John D. Ament 
> wrote:
>
> > I think it's a good idea.  Lots of other projects do something
> > similar.  We could link to a query with this from the proposed
> > contributing guide I emailed about earlier.  If we put the
> > contributing guide on confluence, I believe we can even embed a report.
> >
> > John
> >
> > On Sun, Jul 9, 2017 at 9:34 PM Avia Efrat  wrote:
> >
> > > Today Tal (t...@gigaspaces.com) and myself had a very long and
> > > productive face-to-face session with some AT developers about
> > > ARIA. We did a quick introduction to TOSCA (as some of them where
> > > already familiar with it), followed by an theoretical overview and
> live demo of ARIA 0.1.0.
> > >
> > > Some of the AT guys were very interested in contributing to ARIA,
> > > and raised what I think is a very good suggestion. They said that
> > > since sometimes you don't know where to start when contributing to a
> > > large and unfamiliar project, and since some of them or only novice
> > > python programmers, it would very good for them to have Jiras marked
> > > with a special label, such as 'entry-level', to signal that these
> > > Jiras are suitable for beginners.
> > >
> > > So first, I would like to hear your opinions on this suggestion, and
> > > second, if you support it, maybe you have some better input on the
> > > name
> > of
> > > such a label, as I'm not sure I'm pleased with 'entry-level'. (Some
> > > other suggestions were 'first-time-contributor' and 'trivial', but
> > > feel free to suggest your own)
> > >
> > > --
> > > Avia Efrat
> > > SW Engineer
> > > a...@gigaspaces.com | +972546204553 <+972%2054-620-4553> Cloudify |
> > > http://getcloudify.org <
> > > http://getcloudify.org?utm_source=signaturesatori_
> > medium=email_campaign=general_signature
> > > >
> > >
> > > 
> > > 
> > >     cosmo
> > >
> > > [image: Azure Webinar]
> > > <
> > > http://getcloudify.org/webinars/Azure-plugin-for-
> > cloudify-webinar.html?utm_source=signaturesatori_
> > medium=email_campaign=general_signature
> > > >
> > >
> >
>



-- 
Avia Efrat
SW Engineer
a...@gigaspaces.com | +972546204553
Cloudify | http://getcloudify.org




   
[image: Azure Webinar]

Re: Congrats on the First Release!

[Ran Ziv]

Done:
https://issues.apache.org/jira/browse/ARIA-306 ( with sub-tasks
https://issues.apache.org/jira/browse/ARIA-307 and
https://issues.apache.org/jira/browse/ARIA-308 )
https://issues.apache.org/jira/browse/ARIA-309


On Mon, Jul 10, 2017 at 3:54 PM, John D. Ament 
wrote:

> Ran,
>
> Do you want to create JIRAs for these?
>
> John
>
> On Mon, Jul 10, 2017 at 8:13 AM Ran Ziv  wrote:
>
> > Thanks :)
> >
> > 1) Documenting the release process - I have it on my list and will get it
> > on our Confluence soon. I also wrote some scripts to ease this process,
> > we'll probably merge them onto the repo one way or another soon.
> > 2) The sdist comes with generated HTML pages; We should probably have
> these
> > on our website as well.
> > 3) One already exists on our confluence - here:
> > https://cwiki.apache.org/confluence/display/ARIATOSCA/
> Contributing+to+ARIA
> > and here:
> > https://cwiki.apache.org/confluence/display/ARIATOSCA/Contributing+Code
> > 4) Making things easily discoverable - IMO that's mostly website work,
> need
> > to make sure the website links everywhere needed including our Confluence
> > etc..
> > 5) Downloads page - yup, more website work :)
> >
> >
> > Thanks for the tips, I hope we'll be able to follow up on those shortly.
> >
> >
> >
> > On Mon, Jul 10, 2017 at 1:04 AM, Suneel Marthi 
> > wrote:
> >
> > > Same here, congrats Team on first release.
> > >
> > > On Sun, Jul 9, 2017 at 5:20 PM, John D. Ament 
> > > wrote:
> > >
> > > > All,
> > > >
> > > > I wanted to express my well wishes to you all on a successful first
> > > > release.  Most podlings see this as a milestone, I'll be updating the
> > > > various tracking sheets shortly with this note.
> > > >
> > > > So what's next?  Once the mechanics of a release are squared away,
> > > projects
> > > > figure out ways to grow the community.  Here's a short list of things
> > I'd
> > > > recommend:
> > > >
> > > > - Make sure the release process is documented and that the next
> release
> > > has
> > > > a different release manager.
> > > > - Start putting together developer centric documentation.  This may
> > > include
> > > > some high level architecture, written designs.
> > > > - Put together a contributor's guide.  This may explain how the
> project
> > > > works (via github pull requests), creating JIRA tickets, browsing
> > > fisheye,
> > > > testing locally.
> > > > - Make all of this easily discoverable.  We have a lot of these
> > > documents,
> > > > but they may be hard to find.
> > > > - Make sure we have a downloads page that points to the source
> release
> > > (ASF
> > > > requirement).
> > > >
> > > > John
> > > >
> > >
> >
>

RE: [VOTE] Add an 'entry-level' label to some of our Jira issues

[Steve Baillargeon]

Hi
Do you intend to introduce "other levels" or just one label for beginners?
If you only need one level, then maybe it is best to call it "simple" or 
'basic"?

Hi Avia and Tal,
Is it possible to store the quick introduction to TOSCA and theoretical 
overview for everyone to see?
Thanks

Steve B




-Original Message-
From: Ran Ziv [mailto:r...@gigaspaces.com] 
Sent: Monday, July 10, 2017 4:39 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: [VOTE] Add an 'entry-level' label to some of our Jira issues

I'm all for it, though I don't really like "entry-level" for the name of the 
label :) Any other suggestions?


On Mon, Jul 10, 2017 at 5:09 AM, John D. Ament 
wrote:

> I think it's a good idea.  Lots of other projects do something 
> similar.  We could link to a query with this from the proposed 
> contributing guide I emailed about earlier.  If we put the 
> contributing guide on confluence, I believe we can even embed a report.
>
> John
>
> On Sun, Jul 9, 2017 at 9:34 PM Avia Efrat  wrote:
>
> > Today Tal (t...@gigaspaces.com) and myself had a very long and 
> > productive face-to-face session with some AT developers about 
> > ARIA. We did a quick introduction to TOSCA (as some of them where 
> > already familiar with it), followed by an theoretical overview and live 
> > demo of ARIA 0.1.0.
> >
> > Some of the AT guys were very interested in contributing to ARIA, 
> > and raised what I think is a very good suggestion. They said that 
> > since sometimes you don't know where to start when contributing to a 
> > large and unfamiliar project, and since some of them or only novice 
> > python programmers, it would very good for them to have Jiras marked 
> > with a special label, such as 'entry-level', to signal that these 
> > Jiras are suitable for beginners.
> >
> > So first, I would like to hear your opinions on this suggestion, and 
> > second, if you support it, maybe you have some better input on the 
> > name
> of
> > such a label, as I'm not sure I'm pleased with 'entry-level'. (Some 
> > other suggestions were 'first-time-contributor' and 'trivial', but 
> > feel free to suggest your own)
> >
> > --
> > Avia Efrat
> > SW Engineer
> > a...@gigaspaces.com | +972546204553 <+972%2054-620-4553> Cloudify | 
> > http://getcloudify.org < 
> > http://getcloudify.org?utm_source=signaturesatori_
> medium=email_campaign=general_signature
> > >
> >
> > 
> > 
> >     >
> > [image: Azure Webinar]
> > <
> > http://getcloudify.org/webinars/Azure-plugin-for-
> cloudify-webinar.html?utm_source=signaturesatori_
> medium=email_campaign=general_signature
> > >
> >
>

Re: Congrats on the First Release!

[John D. Ament]

Ran,

Do you want to create JIRAs for these?

John

On Mon, Jul 10, 2017 at 8:13 AM Ran Ziv  wrote:

> Thanks :)
>
> 1) Documenting the release process - I have it on my list and will get it
> on our Confluence soon. I also wrote some scripts to ease this process,
> we'll probably merge them onto the repo one way or another soon.
> 2) The sdist comes with generated HTML pages; We should probably have these
> on our website as well.
> 3) One already exists on our confluence - here:
> https://cwiki.apache.org/confluence/display/ARIATOSCA/Contributing+to+ARIA
> and here:
> https://cwiki.apache.org/confluence/display/ARIATOSCA/Contributing+Code
> 4) Making things easily discoverable - IMO that's mostly website work, need
> to make sure the website links everywhere needed including our Confluence
> etc..
> 5) Downloads page - yup, more website work :)
>
>
> Thanks for the tips, I hope we'll be able to follow up on those shortly.
>
>
>
> On Mon, Jul 10, 2017 at 1:04 AM, Suneel Marthi 
> wrote:
>
> > Same here, congrats Team on first release.
> >
> > On Sun, Jul 9, 2017 at 5:20 PM, John D. Ament 
> > wrote:
> >
> > > All,
> > >
> > > I wanted to express my well wishes to you all on a successful first
> > > release.  Most podlings see this as a milestone, I'll be updating the
> > > various tracking sheets shortly with this note.
> > >
> > > So what's next?  Once the mechanics of a release are squared away,
> > projects
> > > figure out ways to grow the community.  Here's a short list of things
> I'd
> > > recommend:
> > >
> > > - Make sure the release process is documented and that the next release
> > has
> > > a different release manager.
> > > - Start putting together developer centric documentation.  This may
> > include
> > > some high level architecture, written designs.
> > > - Put together a contributor's guide.  This may explain how the project
> > > works (via github pull requests), creating JIRA tickets, browsing
> > fisheye,
> > > testing locally.
> > > - Make all of this easily discoverable.  We have a lot of these
> > documents,
> > > but they may be hard to find.
> > > - Make sure we have a downloads page that points to the source release
> > (ASF
> > > requirement).
> > >
> > > John
> > >
> >
>

Re: Installation issue in 0.1.0 release

[John D. Ament]

IMHO, podlings should try to cut releases frequently.  Gets in the habit of
how to do it.  So if you or someone else has the cycles to cut the release
I say do it.

I personally don't care what version it is, its just a number.

John

On Mon, Jul 10, 2017 at 8:13 AM Ran Ziv  wrote:

> I've found the following issue with the 0.1.0 release:
> https://issues.apache.org/jira/browse/ARIA-304
>
> A fix for this has already been merged into master; PR can be seen here:
> https://github.com/apache/incubator-ariatosca/pull/178
>
>
>
> I'm proposing the possibility of creating a quick 0.1.1 release for fixing
> this bug.
> On one hand it's not necessarily in the main path (requires optional
> dependency installation, not relevant for Windows) and has a simple
> workaround (see comment on the JIRA issue); On the other hand, it's a
> pretty annoying bug that could deter users from using the 0.1.0, and the
> fix is simple.
>
>
> If we're to release a 0.1.1 package, there are a few other bug fixes that
> have been merged since the original 0.1.0 proposal, that we could have as a
> part of this release as well:
> https://issues.apache.org/jira/browse/ARIA-296
> https://issues.apache.org/jira/browse/ARIA-202
> https://issues.apache.org/jira/browse/ARIA-298
> https://issues.apache.org/jira/browse/ARIA-287
>
>
> What do you think?
>
> Ran
>

Installation issue in 0.1.0 release

[Ran Ziv]

I've found the following issue with the 0.1.0 release:
https://issues.apache.org/jira/browse/ARIA-304

A fix for this has already been merged into master; PR can be seen here:
https://github.com/apache/incubator-ariatosca/pull/178



I'm proposing the possibility of creating a quick 0.1.1 release for fixing
this bug.
On one hand it's not necessarily in the main path (requires optional
dependency installation, not relevant for Windows) and has a simple
workaround (see comment on the JIRA issue); On the other hand, it's a
pretty annoying bug that could deter users from using the 0.1.0, and the
fix is simple.


If we're to release a 0.1.1 package, there are a few other bug fixes that
have been merged since the original 0.1.0 proposal, that we could have as a
part of this release as well:
https://issues.apache.org/jira/browse/ARIA-296
https://issues.apache.org/jira/browse/ARIA-202
https://issues.apache.org/jira/browse/ARIA-298
https://issues.apache.org/jira/browse/ARIA-287


What do you think?

Ran

Re: Congrats on the First Release!

[Ran Ziv]

Thanks :)

1) Documenting the release process - I have it on my list and will get it
on our Confluence soon. I also wrote some scripts to ease this process,
we'll probably merge them onto the repo one way or another soon.
2) The sdist comes with generated HTML pages; We should probably have these
on our website as well.
3) One already exists on our confluence - here:
https://cwiki.apache.org/confluence/display/ARIATOSCA/Contributing+to+ARIA
and here:
https://cwiki.apache.org/confluence/display/ARIATOSCA/Contributing+Code
4) Making things easily discoverable - IMO that's mostly website work, need
to make sure the website links everywhere needed including our Confluence
etc..
5) Downloads page - yup, more website work :)


Thanks for the tips, I hope we'll be able to follow up on those shortly.



On Mon, Jul 10, 2017 at 1:04 AM, Suneel Marthi 
wrote:

> Same here, congrats Team on first release.
>
> On Sun, Jul 9, 2017 at 5:20 PM, John D. Ament 
> wrote:
>
> > All,
> >
> > I wanted to express my well wishes to you all on a successful first
> > release.  Most podlings see this as a milestone, I'll be updating the
> > various tracking sheets shortly with this note.
> >
> > So what's next?  Once the mechanics of a release are squared away,
> projects
> > figure out ways to grow the community.  Here's a short list of things I'd
> > recommend:
> >
> > - Make sure the release process is documented and that the next release
> has
> > a different release manager.
> > - Start putting together developer centric documentation.  This may
> include
> > some high level architecture, written designs.
> > - Put together a contributor's guide.  This may explain how the project
> > works (via github pull requests), creating JIRA tickets, browsing
> fisheye,
> > testing locally.
> > - Make all of this easily discoverable.  We have a lot of these
> documents,
> > but they may be hard to find.
> > - Make sure we have a downloads page that points to the source release
> (ASF
> > requirement).
> >
> > John
> >
>

Re: [VOTE] Add an 'entry-level' label to some of our Jira issues

[Ran Ziv]

I'm all for it, though I don't really like "entry-level" for the name of
the label :)
Any other suggestions?


On Mon, Jul 10, 2017 at 5:09 AM, John D. Ament 
wrote:

> I think it's a good idea.  Lots of other projects do something similar.  We
> could link to a query with this from the proposed contributing guide I
> emailed about earlier.  If we put the contributing guide on confluence, I
> believe we can even embed a report.
>
> John
>
> On Sun, Jul 9, 2017 at 9:34 PM Avia Efrat  wrote:
>
> > Today Tal (t...@gigaspaces.com) and myself had a very long and productive
> > face-to-face session with some AT developers about ARIA. We did a quick
> > introduction to TOSCA (as some of them where already familiar with it),
> > followed by an theoretical overview and live demo of ARIA 0.1.0.
> >
> > Some of the AT guys were very interested in contributing to ARIA, and
> > raised what I think is a very good suggestion. They said that since
> > sometimes you don't know where to start when contributing to a large and
> > unfamiliar project, and since some of them or only novice python
> > programmers, it would very good for them to have Jiras marked with a
> > special label, such as 'entry-level', to signal that these Jiras are
> > suitable for beginners.
> >
> > So first, I would like to hear your opinions on this suggestion, and
> > second, if you support it, maybe you have some better input on the name
> of
> > such a label, as I'm not sure I'm pleased with 'entry-level'. (Some other
> > suggestions were 'first-time-contributor' and 'trivial', but feel free to
> > suggest your own)
> >
> > --
> > Avia Efrat
> > SW Engineer
> > a...@gigaspaces.com | +972546204553 <+972%2054-620-4553>
> > Cloudify | http://getcloudify.org
> > <
> > http://getcloudify.org?utm_source=signaturesatori_
> medium=email_campaign=general_signature
> > >
> >
> > 
> > 
> >     >
> > [image: Azure Webinar]
> > <
> > http://getcloudify.org/webinars/Azure-plugin-for-
> cloudify-webinar.html?utm_source=signaturesatori_
> medium=email_campaign=general_signature
> > >
> >
>