Re: pip executable expected as part of plugin install.

[Vaishnavi K . R]

Hi,


There is no change with regards to this in the latest code base.

The following is the error that we get when the pip executable is not found.


Validating plugin /root/testplugin-1.0-py27-none-any.wgn...

Plugin validated successfully

Installing plugin /root/testplugin-1.0-py27-none-any.wgn...

Retrieving source...

Extracting zip /root/testplugin-1.0-py27-none-any.wgn to /tmp/tmp3Q0BL2...

Source is: /tmp/tmp3Q0BL2/testplugin

[Errno 2] No such file or directory



Thanks,

/Vaish


From: Thomas Nadeau 
Sent: Sunday, December 3, 2017 2:57:22 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: pip executable expected as part of plugin install.

DJ,

If when you take a look at this, you find that it fails, please send
detailed log/output
so we can figure this out.  I don’t see any of that from the thread below.

Thx,

—Tom


On Sun, Dec 3, 2017 at 11:22 AM, Tal Liron  wrote:

> Hi DJ,
>
> A lot has changed since August. :) I wonder if you can take a look at the
> current state of master and see if things have improved with wagon
> installs?
>
> On Fri, Dec 1, 2017 at 9:22 AM, D Jayachandran <
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi Ran,
> >
> > Sorry I had missed to answer this thread. Just to answer your question
> > wagon also expects pip as a binary "/usr/bin/pip".  The above path may
> not
> > be the same for al distros of linux and when the path varies we run into
> > the issue/
> > As I already told we could probably fix this issue by using pip as
> library
> > instead of a 3PP.
> > Please let me know if we can also apply the same fix with wagon as well.
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Ran Ziv [mailto:r...@cloudify.co]
> > Sent: Sunday, August 20, 2017 12:40 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: pip executable expected as part of plugin install.
> >
> > Can you try to explain again what's the issue you're seeing with the way
> > Wagon works right now?
> > We could create a pull request for Wagon as well, but I'm not sure I
> > understand the problem at the moment.
> >
> > On Wed, Aug 16, 2017 at 6:04 PM, D Jayachandran <
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Even if we fix the issue in ARIA. Wagon library still uses the same
> > > logic in finding the pip path and it is wrong.
> > > Am not sure how to fix this with wagon.
> > >
> > > Regards,
> > > DJ
> > > -Original Message-
> > > From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> > > Sent: Thursday, August 03, 2017 5:00 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: RE: pip executable expected as part of plugin install.
> > >
> > > Thanks Avia, I will open an issue.
> > >
> > > Regards,
> > > DJ
> > >
> > > -Original Message-
> > > From: Avia Efrat [mailto:a...@cloudify.co]
> > > Sent: Thursday, August 03, 2017 4:01 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: pip executable expected as part of plugin install.
> > >
> > > Hi DJ,
> > > It seems you are correct, I don't see a reason for not using the pip
> > > library.
> > > Maybe it was that way since we didn't want to add pip as a dependency
> > > explicitly (this code is from the beginning of ARIA).
> > >
> > > Feel free to open an issue about that =)
> > >
> > > On Wed, Aug 2, 2017 at 10:19 AM, D Jayachandran <
> > > d.jayachand...@ericsson.com
> > > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Am using a Ubuntu version of linux for my development and ARIA does
> > > > not find the correct path of pip during the plugin install.
> > > > To be precise this happens when pip freeze is executed.
> > > >
> > > > @staticmethod
> > > > def _pip_freeze():
> > > > """Run pip freeze in current environment and return the
> > output"""
> > > > bin_dir = 'Scripts' if os.name == 'nt' else 'bin'
> > > > pip_path = os.path.join(sys.prefix, bin_dir,
> > > > 'pip{0}'.format('.exe' if os.name ==
> > > 'nt'
> > > > else ''))
> > > > pip_freeze = subprocess.Popen([pip_path, 'freeze'],
> > > > stdout=subprocess.PIPE)
> > > > pip_freeze_output, _ = pip_freeze.communicate()
> > > > assert not pip_freeze.poll()
> > > > return pip_freeze_output
> > > >
> > > > Now the question is why are we executing a pip command directly and
> > > > not using pip as a library.
> > > >
> > > >
> > > > Regards,
> > > > DJ
> > > >
> > >
> >
>

Re: Loading Custom Workflows from CSAR

[Vaishnavi K . R]

Hi Tal,


The loading of the python modules with python functions for workflows happens 
when the module is in PYTHONPATH.

But I could also see that, the absolute path of the resource storage with the 
service template ID is added to sys.path to make it available for python.

This facilitates the loading of modules from CSAR, provided the modules are 
present in the root directory of the CSAR.

Am I right?


Thanks,

/Vaish


From: Tal Liron 
Sent: Thursday, December 7, 2017 8:51:49 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Loading Custom Workflows from CSAR

Actually, the current implementation does not use the CSAR: it expects that
the Python function (decorated by @workflow) would be somewhere in the
Python path, and we are currently missing a CSAR code-loading mechanism.

We do not expect the @workflow function structure to change in any way, so
I think you can feel confident about writing custom workflows in this
matter. What might change slightly in the near future is how to package the
.py file.


On Thu, Dec 7, 2017 at 2:57 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:

> Hi
> While the investigation is on-going, I need to double check what can be
> done today.
> But I guess how it is done today might change as well (?)
> Based on our analysis of the latest code base, the loading of the custom
> workflows today is from CSAR only.
> Please advise.
>
> -Steve
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Tuesday, November 28, 2017 2:06 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Loading Custom Workflows from CSAR
>
> Thanks, Steve. We don't have a JIRA for this right now, but we do intend
> to have a way to include "plugins" in a CSAR and have them automatically
> installed. A "plugin" is basically a Python extension to ARIA that can be
> loaded at runtime and contained per service.
>
> This is part of our current general work trying to find a good design for
> plugins generally, and will likely result in a JIRA epic with several
> issues. At this time, I don't think it's worth created this epic if we
> don't have a plan.
>
> The design will likely be inspired by the plugin design in Cloudify, from
> which we grabbed our seed code. However, there is room for some
> re-imagination especially as pertains TOSCA-specific issues.
>
> On Tue, Nov 28, 2017 at 1:01 PM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi
> > As far as I know the implementation string associated with the
> > aria.Workflow type must call or execute a Python function (using the
> > dot
> > notation) that is stored in ARIA, like a plugin.
> > When will it be possible to refer to  a .py file stored in the CSAR
> > instead?
> > Do you have any Jira for this enhancement?
> >
> > Regards
> > Steve B
> >
>

RE: install_aria_extensions called twice

[Srinidhi Srivatsan]

Hi,

Thanks for the information. Will this item be prioritized and fixed?

Regards,
Srinidhi.

-Original Message-
From: Maxim Orlov [mailto:ma...@cloudify.co]
Sent: Wednesday, December 06, 2017 5:59 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: install_aria_extensions called twice

The removal on the call to install_aria_extensions does solve the problem in
your case, however this might raise other issue. For example: writing a
process executor extension would have no effect if you'd remove the
`install_aria_extensions` function call.

The actual problem is caused because you try to pass a complex data_type,
which get pickled. in the unpicking process the extension gets loaded
automatically, and then it get loaded again via the
`install_aria_extensions`. Indeed this is a bug we need to address (I've
opened a JIRA ticket here ).

On Wed, Dec 6, 2017 at 8:59 AM Srinidhi Srivatsan
 wrote:

> Hi,
>
>
>
> We have observed runtime error “Re-definition of YAML 1.1” error while
> executing the following service template. This happens when we define
> a complex type as input into an operation but the first entry must be
> an intrinsic function even if the type has been defined as string. We
> think it maybe because of the install_aria_extensions being called
> twice. When commenting out the “install_aria_extensions” in
> process.py(executor), execution succeeds.
>
>
>
> tosca_definitions_version: tosca_simple_yaml_1_0
>
>
>
> data_types:
>
>   my.datatypes.operation.inputs.Template:
>
> derived_from: tosca.datatypes.Root
>
> properties:
>
>   path:
>
> type: string
>
>   output:
>
> type: my.datatypes.operation.inputs.Template.Output
>
> required: false
>
>
>
>   my.datatypes.operation.inputs.Template.Output:
>
> derived_from: tosca.datatypes.Root
>
> properties:
>
>   runtime_property:
>
> type: string
>
> required: false
>
>   remote_file:
>
> type: my.datatypes.operation.inputs.Template.Output.RemoteFile
>
> required: false
>
>
>
>   my.datatypes.operation.inputs.Template.Output.RemoteFile:
>
> derived_from: tosca.datatypes.Root
>
> properties:
>
>   hostname:
>
> type: string
>
> required: false
>
>   username:
>
> type: string
>
> required: false
>
>   password:
>
> type: string
>
> required: false
>
>   path:
>
> type: string
>
> required: false
>
>
>
> node_types:
>
>   my.nodes.BGW:
>
> derived_from: tosca.nodes.Root
>
> properties:
>
>   host:
>
> type: string
>
> description: bgw host address
>
> interfaces:
>
>   Standard:
>
> type: tosca.interfaces.node.lifecycle.Standard
>
> configure:
>
>   implementation: scripts/test.py
>
>   inputs:
>
> templates:
>
>   type: list
>
>   entry_schema:
>
> type: my.datatypes.operation.inputs.Template
>
> description: "BGW configuration templates"
>
>
>
> topology_template:
>
>
>
> node_templates:
>
>   bgw:
>
> type: my.nodes.BGW
>
> properties:
>
>   host: "{get_input: BGW_HOST }"
>
> interfaces:
>
>   Standard:
>
> configure:
>
>   inputs:
>
> templates:
>
> - path: "configuration-templates/bgw_epg_add"
>
>   output:
>
>   runtime_property: "bgw_epg_add_configuration"
>
>   remote_file:
>
>   hostname: "host" # replace the string with a
> function and you no longer get the error i.e. { get_property: [SELF,
> host] }
>
>   username: "Name"
>
>   password: "Pwd"
>
>   path:  "the path "
>
> - path: "configuration-templates/bgw_mme_add"
>
>
>
> Regards,
>
> Srinidhi.
>
>
>
> *From:* Srinidhi Srivatsan [mailto:srinidhi.srivat...@globallogic.com]
> *Sent:* Wednesday, December 06, 2017 11:41 AM
> *To:* 'dev@ariatosca.incubator.apache.org'
> *Subject:* install_aria_extensions called twice
>
>
>
> Hi,
>
>
>
>We have observed that install_aria_extensions is called twice –
> once in
> process.py(executor) and once in main.py. Could you please confirm as
> to why it is called again in process.py?
>
>
>
> Regards,
>
> Srinidhi.
>

RE: Node Template Substitution

[Steve Baillargeon]

Hi Avia
I don't access to the design doc. Am I missing something?

Will 0.2.0 support YAML Profile 1.0 or 1.2 topology substitution?
Or is it postponed to later?

-Steve

-Original Message-
From: Avia Efrat [mailto:a...@cloudify.co] 
Sent: Tuesday, October 17, 2017 4:44 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Node Template Substitution

There are plans to extend substitution mappings support to TOSCA 1.2, just as 
any other change/improvement in the 1.2 profile.

A CSAR with one 'main' service template and other service templates will be 
stored as one service template, and will have one unique name.

The design doc:
https://drive.google.com/open?id=19nPjSj6mJyXWd4KLxPqRNp_TPqLpvXjzj98NXrAmcjc


Additional v1.2 issues (a non-exhaustive list):
https://docs.google.com/document/d/18yZC8qIWMbWBeULOzmLTT_oVrZXQ3z4030U6JIXdJ84/edit


On Sat, Oct 14, 2017 at 2:10 AM, Steve Baillargeon < 
steve.baillarg...@ericsson.com> wrote:

> Hi Avia
> One more question.
>
> Say we have a CSAR that contains multiple TOSCA YAML files e.g. a 
> top-level ST and a bunch of low-level STs.
> I am assuming all those TOSCA service templates (all of them have a 
> full topology section) will be stored as a single “service-template” 
> in ARIA and a single unique name is needed to represent such single 
> “service-template”
> composed of multiple topologies.
> Is this correct?
>
> -Steve
>
> -Original Message-
> From: Steve Baillargeon
> Sent: Wednesday, October 11, 2017 11:29 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: Node Template Substitution
>
> Hi Avia
> Is it possible to review the design documentation for it?
> Do you have a doc or a few notes describing how ARIA will perform 
> "best matching" based on YAML 1.0/1.1 profile?
>
> The full support for NFV Profile 1.0 requires Node Template 
> Substitution defined in YAML 1.2 profile.
> Any future plans for ARIA to extend Node Template Substitution as 
> defined in YAML 1.2 profile ?
>
> Regards
> Steve B
>
> -Original Message-
> From: Arthur Berezin [mailto:art...@cloudify.co]
> Sent: Tuesday, October 10, 2017 12:20 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Node Template Substitution
>
> Avia, can you please post a link to the design?  thanks
>
> On Mon, Oct 9, 2017 at 5:14 PM Avia Efrat  wrote:
>
> > Currently the design is finished, and it is on a small hold for now.
> > The plan is to support the 1.0/1.1 profile.
> >
> > On Wed, Oct 4, 2017 at 7:50 PM, Steve Baillargeon < 
> > steve.baillarg...@ericsson.com> wrote:
> >
> > > Hi
> > > Can we have a status update on the availability of the Node 
> > > Template Substitution feature (aka substitution mappings)?
> > > Will it support the "capabilities" defined in YAML Profile 1.0 or 
> > > YAML Profile 1.2?
> > >
> > > Regards
> > > Steve B
> > >
> > >
> >
>

Re: Website Build + Release

[Thomas Nadeau]

Cool. Lets work together on this, so that more than 1 person learns how 
this works. 8)

—Tom


> On Dec 7, 2017, at 6:51 PM, Arthur Berezin  wrote:
> 
> I can pick this one up.
> 
> Arthur
> 
> On Thu, Dec 7, 2017, 17:13 John D. Ament  wrote:
> 
>> Tom,
>> 
>> I don't know how to do this, so I'd recommend someone else jump in to take
>> care of it.  I would recommend as an immediate step to update the website
>> with the 0.1.1 release docs to avoid downloading the release on each build.
>> 
>> John
>> 
>> On Thu, Dec 7, 2017 at 5:06 AM Thomas Nadeau  wrote:
>> 
>>> John,
>>> 
>>> Can I help you with this or is this something you can do quickly?
>>> 
>>> --Tom
>>> 
>>> 
>>> On Wed, Dec 6, 2017 at 10:01 PM, Arthur Berezin 
>>> wrote:
>>> 
 John, +1.
 
 Let's update the aria's release process to push  sphynx update on Aria
 releases.
 
 The reason the website is currently pulling the release docs and not
>> the
 other way around is because we published the docs right after we
>> released
 0.1.1 and didn't want to introduce changes in that point in time.
 
 Arthur.
 
 On Wed, Dec 6, 2017, 16:58 Thomas Nadeau 
>> wrote:
 
> 
> 
>> On Dec 6, 2017, at 4:40 PM, John D. Ament 
 wrote:
>> 
>> Tom,
>> 
>> Based on what I'm seeing, you're getting the current release
>> (0.1.1).
> I'm
>> not seeing anything that pulls the current master into the site.
>> 
>> I would recommend that we push from the build to the website,
>> rather
 than
>> have the website pull this information in.
> 
>Ok. Ill take a look shortly.
> 
>—Tom
> 
> 
>> 
>> John
>> 
>> On Wed, Dec 6, 2017 at 8:59 AM Thomas Nadeau <
>> tnadeaua...@gmail.com>
> wrote:
>> 
>>> We use 2 tools to generate the website: Jekyll (html) and spynx
 (docs),
> and
>>> both tools generate outputs based on the latest code.
>>> 
>>> --Tom
>>> 
>>> 
>>> On Wed, Dec 6, 2017 at 1:28 PM, John D. Ament <
>>> johndam...@apache.org>
>>> wrote:
>>> 
 All,
 
 I'm troubleshooting from yesterday's identified website issues.
>>> One
>>> thing
 I noticed is that as a part of the website build, we download our
>>> release.
 Why is that?
 
 John
 
>>> 
> 
> 
 
>>> 
>> 

Re: Website Build + Release

[Arthur Berezin]

I can pick this one up.

Arthur

On Thu, Dec 7, 2017, 17:13 John D. Ament  wrote:

> Tom,
>
> I don't know how to do this, so I'd recommend someone else jump in to take
> care of it.  I would recommend as an immediate step to update the website
> with the 0.1.1 release docs to avoid downloading the release on each build.
>
> John
>
> On Thu, Dec 7, 2017 at 5:06 AM Thomas Nadeau  wrote:
>
> > John,
> >
> > Can I help you with this or is this something you can do quickly?
> >
> > --Tom
> >
> >
> > On Wed, Dec 6, 2017 at 10:01 PM, Arthur Berezin 
> > wrote:
> >
> > > John, +1.
> > >
> > > Let's update the aria's release process to push  sphynx update on Aria
> > > releases.
> > >
> > > The reason the website is currently pulling the release docs and not
> the
> > > other way around is because we published the docs right after we
> released
> > > 0.1.1 and didn't want to introduce changes in that point in time.
> > >
> > > Arthur.
> > >
> > > On Wed, Dec 6, 2017, 16:58 Thomas Nadeau 
> wrote:
> > >
> > > >
> > > >
> > > > > On Dec 6, 2017, at 4:40 PM, John D. Ament 
> > > wrote:
> > > > >
> > > > > Tom,
> > > > >
> > > > > Based on what I'm seeing, you're getting the current release
> (0.1.1).
> > > > I'm
> > > > > not seeing anything that pulls the current master into the site.
> > > > >
> > > > > I would recommend that we push from the build to the website,
> rather
> > > than
> > > > > have the website pull this information in.
> > > >
> > > > Ok. Ill take a look shortly.
> > > >
> > > > —Tom
> > > >
> > > >
> > > > >
> > > > > John
> > > > >
> > > > > On Wed, Dec 6, 2017 at 8:59 AM Thomas Nadeau <
> tnadeaua...@gmail.com>
> > > > wrote:
> > > > >
> > > > >> We use 2 tools to generate the website: Jekyll (html) and spynx
> > > (docs),
> > > > and
> > > > >> both tools generate outputs based on the latest code.
> > > > >>
> > > > >> --Tom
> > > > >>
> > > > >>
> > > > >> On Wed, Dec 6, 2017 at 1:28 PM, John D. Ament <
> > johndam...@apache.org>
> > > > >> wrote:
> > > > >>
> > > > >>> All,
> > > > >>>
> > > > >>> I'm troubleshooting from yesterday's identified website issues.
> > One
> > > > >> thing
> > > > >>> I noticed is that as a part of the website build, we download our
> > > > >> release.
> > > > >>> Why is that?
> > > > >>>
> > > > >>> John
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>

starting .3 release delayed

[Thomas Nadeau]

I just wanted to let folks know that I wasn't able to get the release
script kicked off today and I need to split for the airport for a super
long ride home, so I'll likely only get back to this next Monday first
thing EST.

Committers: if you merge any PRs between now and then, please ensure that
master is stable by Monday so I can start things off when I get back online.

Cheers,

--Tom

Re: Time for a new release

[Thomas Nadeau]

Question about the instructions. It says:

If this is your first time creating a release for ARIA, make sure to update
the KEYS file
 with your
key


I went ahead and generated a new key, and amended it to the KEYS file that
I found at the URL above which is located here:

https://dist.apache.org/repos/dist/dev/incubator/ariatosca/KEYS

I have stored locally.

How does one modify the actual file in the release area?  The release
script that we have doesn't take it as an argument when it pushes the other
artifacts.

--Tom




On Thu, Dec 7, 2017 at 5:14 PM, John D. Ament  wrote:

> Thomas,
>
> I believe the release process was documented on confluence by prior release
> manager.
> https://cwiki.apache.org/confluence/display/ARIATOSCA/Release+Process
>
> John
>
> On Thu, Dec 7, 2017 at 7:30 AM Thomas Nadeau 
> wrote:
>
> > Community,
> >
> > At last week's grooming we agreed that I would invoke the next release of
> > Aria (.3) after certain critical PRs were merged. We are at that time
> now,
> > so I wanted to begin the process.  That leads me to my next question...
> >
> > Mentors: is there a document describing the steps to take?  There is a
> > script in our repository under releases that appears to have all the
> steps
> > for creating all of our release candidate artifacts, but I am unsure if I
> > need to have the committers/PMCC vote before that is created, afterwards
> or
> > both.  I also believe that the apache full PMC is supposed to have some
> > time to review the release candidate too.
> >
> > Thanks,
> >
> > --Tom
> >
>

Re: Time for a new release

[Thomas Nadeau]

Got it. Thanks. Ill follow those instructions and get this kicked off.

--Tom


On Thu, Dec 7, 2017 at 5:14 PM, John D. Ament  wrote:

> Thomas,
>
> I believe the release process was documented on confluence by prior release
> manager.
> https://cwiki.apache.org/confluence/display/ARIATOSCA/Release+Process
>
> John
>
> On Thu, Dec 7, 2017 at 7:30 AM Thomas Nadeau 
> wrote:
>
> > Community,
> >
> > At last week's grooming we agreed that I would invoke the next release of
> > Aria (.3) after certain critical PRs were merged. We are at that time
> now,
> > so I wanted to begin the process.  That leads me to my next question...
> >
> > Mentors: is there a document describing the steps to take?  There is a
> > script in our repository under releases that appears to have all the
> steps
> > for creating all of our release candidate artifacts, but I am unsure if I
> > need to have the committers/PMCC vote before that is created, afterwards
> or
> > both.  I also believe that the apache full PMC is supposed to have some
> > time to review the release candidate too.
> >
> > Thanks,
> >
> > --Tom
> >
>

Re: Time for a new release

[Thomas Nadeau]

I added the report to the confluence wiki here:

https://cwiki.apache.org/confluence/display/ARIATOSCA/Podling+Report+2017-DEC-12



On Thu, Dec 7, 2017 at 5:14 PM, John D. Ament  wrote:

> Thomas,
>
> I believe the release process was documented on confluence by prior release
> manager.
> https://cwiki.apache.org/confluence/display/ARIATOSCA/Release+Process
>
> John
>
> On Thu, Dec 7, 2017 at 7:30 AM Thomas Nadeau 
> wrote:
>
> > Community,
> >
> > At last week's grooming we agreed that I would invoke the next release of
> > Aria (.3) after certain critical PRs were merged. We are at that time
> now,
> > so I wanted to begin the process.  That leads me to my next question...
> >
> > Mentors: is there a document describing the steps to take?  There is a
> > script in our repository under releases that appears to have all the
> steps
> > for creating all of our release candidate artifacts, but I am unsure if I
> > need to have the committers/PMCC vote before that is created, afterwards
> or
> > both.  I also believe that the apache full PMC is supposed to have some
> > time to review the release candidate too.
> >
> > Thanks,
> >
> > --Tom
> >
>

Re: Time for a new release

[Thomas Nadeau]

The doc is done.  Can you please take a look [see link below]?

Also, is there a final resting place for the document other than the 
Confluence Wiki?

—Tom


> On Dec 7, 2017, at 5:14 PM, John D. Ament  wrote:
> 
> Thomas,
> 
> I believe the release process was documented on confluence by prior release
> manager.
> https://cwiki.apache.org/confluence/display/ARIATOSCA/Release+Process
> 
> John
> 
> On Thu, Dec 7, 2017 at 7:30 AM Thomas Nadeau  wrote:
> 
>> Community,
>> 
>> At last week's grooming we agreed that I would invoke the next release of
>> Aria (.3) after certain critical PRs were merged. We are at that time now,
>> so I wanted to begin the process.  That leads me to my next question...
>> 
>> Mentors: is there a document describing the steps to take?  There is a
>> script in our repository under releases that appears to have all the steps
>> for creating all of our release candidate artifacts, but I am unsure if I
>> need to have the committers/PMCC vote before that is created, afterwards or
>> both.  I also believe that the apache full PMC is supposed to have some
>> time to review the release candidate too.
>> 
>> Thanks,
>> 
>> --Tom
>> 

Re: Loading custom workflows

[Tal Liron]

We had some good discussions are are just about ready to make them public
for soliciting feedback.

I will handle it next week and let the mailing list know!

On Thu, Dec 7, 2017 at 2:31 PM, Thomas Nadeau  wrote:

> Do you think it is a good idea to start a document and/or wiki entry for a
> thumbnail sketch of how we want to do this?
>
> --Tom
>
> On Thu, Dec 7, 2017 at 2:04 PM, Tal Liron  wrote:
>
> > Our current idea is to support multiple ways of installing extensions.
> One
> > of them will, of course, be by including them in the CSAR file (which can
> > be done in various ways: Python source code, wheels, wagons, etc.). We
> want
> > to standardize all extensions with a single well-defined entry point.
> >
> > On Wed, Dec 6, 2017 at 4:58 PM, Vaishnavi K.R <
> vaishnavi@ericsson.com>
> > wrote:
> >
> > > Hi Tal,
> > >
> > >
> > > Good that this has been considered.
> > >
> > > As all the three entities are mere python modules, it is good to have a
> > > common loading mechanism.
> > >
> > > But will there be any major change in the existing way of loading
> plugins
> > > and using the same in the service template?
> > >
> > >
> > > Thanks,
> > >
> > > /Vaish
> > >
> > > 
> > > From: Tal Liron 
> > > Sent: Wednesday, December 6, 2017 7:27:02 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Loading custom workflows
> > >
> > > Great question, and it was asked very recently on this list ...
> > >
> > > There is a need for a unified way to dynamically load
> > > extensions/plugins/workflows from CSAR files as well as other places.
> We
> > > are trying to come with a good, forward-looking architectural design
> for
> > > this loading mechanism. I will provide an update on this in the next
> few
> > > days.
> > >
> > > On Wed, Dec 6, 2017 at 3:51 PM, Vaishnavi K.R <
> > vaishnavi@ericsson.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > >
> > > > I tried using the custom workflow support provided by ARIA.
> > > >
> > > > In the current ARIA, the custom workflows are directly imported as
> > python
> > > > modules.
> > > >
> > > > It looks like it is loading the python modules that are bundled along
> > > with
> > > > the service template in CSAR.
> > > >
> > > >
> > > > Also I could see that you have plans to load it as how the plugins
> are.
> > > >
> > > > Is anyone working on this?
> > > >
> > > > Will the workflows be packaged as wagon archives and installed?
> > > >
> > > > Will they be referred in the service template with the same
> convention
> > as
> > > > plugins?
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > /Vaish
> > > >
> > >
> >
>

Re: Loading Custom Workflows from CSAR

[Tal Liron]

Actually, the current implementation does not use the CSAR: it expects that
the Python function (decorated by @workflow) would be somewhere in the
Python path, and we are currently missing a CSAR code-loading mechanism.

We do not expect the @workflow function structure to change in any way, so
I think you can feel confident about writing custom workflows in this
matter. What might change slightly in the near future is how to package the
.py file.


On Thu, Dec 7, 2017 at 2:57 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:

> Hi
> While the investigation is on-going, I need to double check what can be
> done today.
> But I guess how it is done today might change as well (?)
> Based on our analysis of the latest code base, the loading of the custom
> workflows today is from CSAR only.
> Please advise.
>
> -Steve
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Tuesday, November 28, 2017 2:06 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Loading Custom Workflows from CSAR
>
> Thanks, Steve. We don't have a JIRA for this right now, but we do intend
> to have a way to include "plugins" in a CSAR and have them automatically
> installed. A "plugin" is basically a Python extension to ARIA that can be
> loaded at runtime and contained per service.
>
> This is part of our current general work trying to find a good design for
> plugins generally, and will likely result in a JIRA epic with several
> issues. At this time, I don't think it's worth created this epic if we
> don't have a plan.
>
> The design will likely be inspired by the plugin design in Cloudify, from
> which we grabbed our seed code. However, there is room for some
> re-imagination especially as pertains TOSCA-specific issues.
>
> On Tue, Nov 28, 2017 at 1:01 PM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi
> > As far as I know the implementation string associated with the
> > aria.Workflow type must call or execute a Python function (using the
> > dot
> > notation) that is stored in ARIA, like a plugin.
> > When will it be possible to refer to  a .py file stored in the CSAR
> > instead?
> > Do you have any Jira for this enhancement?
> >
> > Regards
> > Steve B
> >
>

Re: AriaTosca December Podling Report

[John D. Ament]

Thomas,

The report was due yesterday.

John

On Thu, Dec 7, 2017 at 2:50 AM Thomas Nadeau  wrote:

> Just to give a little more info than the original sharing link message.
> The mentors
> asked me to share the document with the community that I am using to create
> the next podling report.  This way anyone here can provide inputs/edits. I
> plan on
> submitting this early next Monday, December 11, 2017 at 5PM EST, so please
> get your edits/comments into the document or to me by then.
>
> Cheers,
>
> --Tom
>
>
>
> On Thu, Dec 7, 2017 at 9:47 AM, Thomas Nadeau (via Google Docs) <
> tnadeaua...@gmail.com> wrote:
>
> > tnadeaua...@gmail.com has shared a link to the following document:
> > AriaTosca December Podling Report
> > <
> https://docs.google.com/document/d/1Yg9J-9WD81UjqvwFoc8wek8628RSLzIEZogtVT1HBWg/edit?usp=sharing_eil=5a28f21c
> >
> > Open in Docs
> > <
> https://docs.google.com/document/d/1Yg9J-9WD81UjqvwFoc8wek8628RSLzIEZogtVT1HBWg/edit?usp=sharing_eip=5a28f21c
> >
> > Google Docs: Create and edit documents online.
> > Google Inc. 1600 Amphitheatre Parkway, Mountain View,
> 
> CA 94043, USA
> > <
> https://maps.google.com/?q=1600+Amphitheatre+Parkway,+Mountain+View,+CA+94043,+USA=gmail=g
> >
> > You have received this email because someone shared a document with you
> > from Google Docs. [image: Logo for Google Docs] <
> https://drive.google.com>
> >
>

Re: Website Build + Release

[John D. Ament]

Tom,

I don't know how to do this, so I'd recommend someone else jump in to take
care of it.  I would recommend as an immediate step to update the website
with the 0.1.1 release docs to avoid downloading the release on each build.

John

On Thu, Dec 7, 2017 at 5:06 AM Thomas Nadeau  wrote:

> John,
>
> Can I help you with this or is this something you can do quickly?
>
> --Tom
>
>
> On Wed, Dec 6, 2017 at 10:01 PM, Arthur Berezin 
> wrote:
>
> > John, +1.
> >
> > Let's update the aria's release process to push  sphynx update on Aria
> > releases.
> >
> > The reason the website is currently pulling the release docs and not the
> > other way around is because we published the docs right after we released
> > 0.1.1 and didn't want to introduce changes in that point in time.
> >
> > Arthur.
> >
> > On Wed, Dec 6, 2017, 16:58 Thomas Nadeau  wrote:
> >
> > >
> > >
> > > > On Dec 6, 2017, at 4:40 PM, John D. Ament 
> > wrote:
> > > >
> > > > Tom,
> > > >
> > > > Based on what I'm seeing, you're getting the current release (0.1.1).
> > > I'm
> > > > not seeing anything that pulls the current master into the site.
> > > >
> > > > I would recommend that we push from the build to the website, rather
> > than
> > > > have the website pull this information in.
> > >
> > > Ok. Ill take a look shortly.
> > >
> > > —Tom
> > >
> > >
> > > >
> > > > John
> > > >
> > > > On Wed, Dec 6, 2017 at 8:59 AM Thomas Nadeau 
> > > wrote:
> > > >
> > > >> We use 2 tools to generate the website: Jekyll (html) and spynx
> > (docs),
> > > and
> > > >> both tools generate outputs based on the latest code.
> > > >>
> > > >> --Tom
> > > >>
> > > >>
> > > >> On Wed, Dec 6, 2017 at 1:28 PM, John D. Ament <
> johndam...@apache.org>
> > > >> wrote:
> > > >>
> > > >>> All,
> > > >>>
> > > >>> I'm troubleshooting from yesterday's identified website issues.
> One
> > > >> thing
> > > >>> I noticed is that as a part of the website build, we download our
> > > >> release.
> > > >>> Why is that?
> > > >>>
> > > >>> John
> > > >>>
> > > >>
> > >
> > >
> >
>

Time for a new release

[Thomas Nadeau]

Community,

At last week's grooming we agreed that I would invoke the next release of
Aria (.3) after certain critical PRs were merged. We are at that time now,
so I wanted to begin the process.  That leads me to my next question...

Mentors: is there a document describing the steps to take?  There is a
script in our repository under releases that appears to have all the steps
for creating all of our release candidate artifacts, but I am unsure if I
need to have the committers/PMCC vote before that is created, afterwards or
both.  I also believe that the apache full PMC is supposed to have some
time to review the release candidate too.

Thanks,

--Tom

Re: Loading custom workflows

[Tal Liron]

Our current idea is to support multiple ways of installing extensions. One
of them will, of course, be by including them in the CSAR file (which can
be done in various ways: Python source code, wheels, wagons, etc.). We want
to standardize all extensions with a single well-defined entry point.

On Wed, Dec 6, 2017 at 4:58 PM, Vaishnavi K.R 
wrote:

> Hi Tal,
>
>
> Good that this has been considered.
>
> As all the three entities are mere python modules, it is good to have a
> common loading mechanism.
>
> But will there be any major change in the existing way of loading plugins
> and using the same in the service template?
>
>
> Thanks,
>
> /Vaish
>
> 
> From: Tal Liron 
> Sent: Wednesday, December 6, 2017 7:27:02 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Loading custom workflows
>
> Great question, and it was asked very recently on this list ...
>
> There is a need for a unified way to dynamically load
> extensions/plugins/workflows from CSAR files as well as other places. We
> are trying to come with a good, forward-looking architectural design for
> this loading mechanism. I will provide an update on this in the next few
> days.
>
> On Wed, Dec 6, 2017 at 3:51 PM, Vaishnavi K.R 
> wrote:
>
> > Hi,
> >
> >
> > I tried using the custom workflow support provided by ARIA.
> >
> > In the current ARIA, the custom workflows are directly imported as python
> > modules.
> >
> > It looks like it is loading the python modules that are bundled along
> with
> > the service template in CSAR.
> >
> >
> > Also I could see that you have plans to load it as how the plugins are.
> >
> > Is anyone working on this?
> >
> > Will the workflows be packaged as wagon archives and installed?
> >
> > Will they be referred in the service template with the same convention as
> > plugins?
> >
> >
> > Thanks,
> >
> > /Vaish
> >
>

Re: Website Build + Release

[Thomas Nadeau]

John,

Can I help you with this or is this something you can do quickly?

--Tom


On Wed, Dec 6, 2017 at 10:01 PM, Arthur Berezin  wrote:

> John, +1.
>
> Let's update the aria's release process to push  sphynx update on Aria
> releases.
>
> The reason the website is currently pulling the release docs and not the
> other way around is because we published the docs right after we released
> 0.1.1 and didn't want to introduce changes in that point in time.
>
> Arthur.
>
> On Wed, Dec 6, 2017, 16:58 Thomas Nadeau  wrote:
>
> >
> >
> > > On Dec 6, 2017, at 4:40 PM, John D. Ament 
> wrote:
> > >
> > > Tom,
> > >
> > > Based on what I'm seeing, you're getting the current release (0.1.1).
> > I'm
> > > not seeing anything that pulls the current master into the site.
> > >
> > > I would recommend that we push from the build to the website, rather
> than
> > > have the website pull this information in.
> >
> > Ok. Ill take a look shortly.
> >
> > —Tom
> >
> >
> > >
> > > John
> > >
> > > On Wed, Dec 6, 2017 at 8:59 AM Thomas Nadeau 
> > wrote:
> > >
> > >> We use 2 tools to generate the website: Jekyll (html) and spynx
> (docs),
> > and
> > >> both tools generate outputs based on the latest code.
> > >>
> > >> --Tom
> > >>
> > >>
> > >> On Wed, Dec 6, 2017 at 1:28 PM, John D. Ament 
> > >> wrote:
> > >>
> > >>> All,
> > >>>
> > >>> I'm troubleshooting from yesterday's identified website issues.  One
> > >> thing
> > >>> I noticed is that as a part of the website build, we download our
> > >> release.
> > >>> Why is that?
> > >>>
> > >>> John
> > >>>
> > >>
> >
> >
>