Re: Support for extension point during service execution

[Tal Liron]

It seems we have duplicated efforts here. DeWayne has separately created a
REST layer for the ONAP project.

DeWayne, could you provide more details?

On Wed, Nov 29, 2017 at 11:59 PM, D Jayachandran <
d.jayachand...@ericsson.com> wrote:

> Hi Tal,
>
> For our use case we have already built a REST Layer on top of ARIA for
> service-template, services and execution creation/start.
> Now for this particular use-case we were looking if we could take the
> service model object and create a service context object out of it, to be
> provided to the service level plugin.
> I was thinking if we had to do this, can this be included as part of ARIA
> (Atleast creation of service context object)
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Wednesday, November 29, 2017 1:46 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Support for extension point during service execution
>
> We half do. :) Actually, this has become a major topic of discussion
> recently on other lists. There's some room to discuss exactly what and how
> is available to the ctx proxy. Right now it's both too unrestricted and too
> narrow. The current idea is to make the exposure more explicit, and
> possibly align it with a more general REST API.
>
> On Wed, Nov 29, 2017 at 12:34 AM, D Jayachandran <
> d.jayachand...@ericsson.com> wrote:
>
> > Hi Tal,
> >
> > I agree with your points mentioned below but I was thinking do we need
> > to have a ServiceLevel operation context, as we now have Node
> > operation context.
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Friday, November 24, 2017 10:12 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Support for extension point during service execution
> >
> > Hi DJ,
> >
> > The question here is why use ARIA's orchestrator at all? It sounds
> > like you have your own orchestration engine. This is an intended use
> > case for ARIA (and indeed was used in the OPEN-O project).
> >
> > There are a few ways to use ARIA here:
> >
> > 1) You can use the ARIA's Python API and access all the data models
> > directly. Of course this will only work if your own orchestration code
> > is in Python.
> > 2) You can use ARIA's CLI to emit the data models you need in either
> > JSON or YAML format, for easy consumption by your code: aria services
> > show myservice --json. Note that you can also wrap ARIA's CLI in an HTTP
> service.
> > 3) You can access the database directly. ARIA uses a a normalized
> > relational (SQL) database.
> >
> > There are some challenges and limitations to each approach. If you
> > tell us what you're going to do we can help you move along in that
> direction.
> >
> >
> > On Fri, Nov 24, 2017 at 7:37 AM, D Jayachandran <
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Hi Team,
> > >
> > > We are looking at an execution point during a service execution
> > > through a plugin. With this the execution will not go through the
> > > workflow runner
> > > (install/uninstall) defined by the orchestrator but the services
> > > instance context object will be provided to the plugin which will
> > > take care of the complete service-execution.
> > > This plugin is looked upon as a "service plugin" which will get the
> > > entire service model object and will provide the details to the
> > > external workflow engine.
> > > We need this feature to enable the execution of workflows which some
> > > of our users already have. Please let us know your thoughts on this
> > > as we have already started our technical study on this.
> > >
> > >
> > > Regards,
> > > DJ
> > >
> >
>

Re: problem using cloudify extension with dev branch

[Maxim Orlov]

The extension repo was built based on Aria 0.1.1 base code. The dependency
is strictly set to 0.1.1 , which kinda make sense since 0.2.0 wasn't (and
still isn't) released. It probably uninstalls the 0.2.0 one and installs
0.1.1 instead, which sound to me as a wanted behavior.

On Thu, Nov 30, 2017, 01:06 Tal Liron  wrote:

> Ah, the dreaded multi-repo problems that I so detest, and am trying to
> avoid by having it all in one repo...
>
> The issue is that you are using a newer version of aria-extension-cloudify
> than what is supported by aria on PyPI. I suggest keeping the two versions
> matching to avoid problems.
>
> On Wed, Nov 29, 2017 at 5:03 PM, DeWayne Filppi 
> wrote:
>
> > I worked around this by installing the cloudify extention using the
> > --no-deps argument (to pip).
> >
> > On Wed, Nov 29, 2017 at 2:32 PM, DeWayne Filppi 
> > wrote:
> >
> > > OK.  I guess I didn't provide enough context.  I installed the ARIA-1
> > > branch of ARIA in order to pick up a bug fix I needed.  When attempting
> > to
> > > install aria-extension-cloudify, it complains that ariatosca 0.2.0 is
> > > installed, and it proceeds to remove it.  So, the cloudify extension
> > > deletes ARIA, apparently because it's looking for a different version
> of
> > > it.  The full message:
> > >
> > > Installing collected packages: apache-ariatosca,
> aria-extension-cloudify
> > > Found existing installation: apache-ariatosca 0.2.0
> > > Uninstalling apache-ariatosca-0.2.0:
> > > Successfully uninstalled apache-ariatosca-0.2.0
> > > Running setup.py develop for apache-ariatosca
> > > Complete output from command /home/vagrant/venv/bin/python -c "import
> > > setuptools, tokenize;__file__='/home/vagrant/venv/src/apache-
> > > ariatosca/setup.py';f=getattr(tokenize, 'open',
> > > open)(__file__);code=f.read().replace('\r\n',
> > > '\n');f.close();exec(compile(code, __file__, 'exec'))" develop
> --no-deps
> > > --prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1:
> > > running develop
> > > Checking .pth file support in /home/vagrant/.aria/plugins/
> > > aria-extension-cloudify-4.1/lib/python2.7/site-packages
> > > /home/vagrant/venv/bin/python -E -c pass
> > > TEST FAILED: /home/vagrant/.aria/plugins/aria-extension-cloudify-4.1/
> > lib/python2.7/site-packages
> > > does NOT support .pth files
> > > error: bad install directory or PYTHONPATH
> > > Command "/home/vagrant/venv/bin/python -c "import setuptools,
> > > tokenize;__file__='/home/vagrant/venv/src/apache-
> > > ariatosca/setup.py';f=getattr(tokenize, 'open',
> > > open)(__file__);code=f.read().replace('\r\n',
> > > '\n');f.close();exec(compile(code, __file__, 'exec'))" develop
> --no-deps
> > > --prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1"
> failed
> > > with error code 1 in /home/vagrant/venv/src/apache-ariatosca/
> > > Could not install package: aria-extension-cloudify (Command
> > > "/home/vagrant/venv/bin/python -c "import setuptools,
> > > tokenize;__file__='/home/vagrant/venv/src/apache-
> > > ariatosca/setup.py';f=getattr(tokenize, 'open',
> > > open)(__file__);code=f.read().replace('\r\n',
> > > '\n');f.close();exec(compile(code, __file__, 'exec'))" develop
> --no-deps
> > > --prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1"
> failed
> > > with error code 1 in /home/vagrant/venv/src/apache-ariatosca/)
> > >
> > >
> > > On Wed, Nov 29, 2017 at 11:13 AM, Tal Liron  wrote:
> > >
> > >> Sorry, hard to understand exactly what you're trying to do, what's
> > >> "failing" etc.
> > >>
> > >> All I can gather from this is that you are installing something that
> > >> requires "apache-ariatosca" but that is already installed, so it's
> > >> removing
> > >> it in order to upgrade. You stopped the log there.
> > >>
> > >> On Wed, Nov 29, 2017 at 1:08 PM, DeWayne Filppi 
> > >> wrote:
> > >>
> > >> > I see the following when trying to install the cloudify extension
> with
> > >> the
> > >> > ARIA-1 branch:
> > >> >
> > >> > Installing collected packages: apache-ariatosca,
> > aria-extension-cloudify
> > >> > Found existing installation: apache-ariatosca 0.2.0
> > >> > Uninstalling apache-ariatosca-0.2.0:
> > >> >
> > >> > Then it fails.
> > >> >
> > >>
> > >
> > >
> >
>

RE: Support for extension point during service execution

[D Jayachandran]

Hi Tal,

For our use case we have already built a REST Layer on top of ARIA for 
service-template, services and execution creation/start.
Now for this particular use-case we were looking if we could take the service 
model object and create a service context object out of it, to be provided to 
the service level plugin.
I was thinking if we had to do this, can this be included as part of ARIA 
(Atleast creation of service context object)

Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Wednesday, November 29, 2017 1:46 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Support for extension point during service execution

We half do. :) Actually, this has become a major topic of discussion recently 
on other lists. There's some room to discuss exactly what and how is available 
to the ctx proxy. Right now it's both too unrestricted and too narrow. The 
current idea is to make the exposure more explicit, and possibly align it with 
a more general REST API.

On Wed, Nov 29, 2017 at 12:34 AM, D Jayachandran < d.jayachand...@ericsson.com> 
wrote:

> Hi Tal,
>
> I agree with your points mentioned below but I was thinking do we need 
> to have a ServiceLevel operation context, as we now have Node 
> operation context.
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Friday, November 24, 2017 10:12 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Support for extension point during service execution
>
> Hi DJ,
>
> The question here is why use ARIA's orchestrator at all? It sounds 
> like you have your own orchestration engine. This is an intended use 
> case for ARIA (and indeed was used in the OPEN-O project).
>
> There are a few ways to use ARIA here:
>
> 1) You can use the ARIA's Python API and access all the data models 
> directly. Of course this will only work if your own orchestration code 
> is in Python.
> 2) You can use ARIA's CLI to emit the data models you need in either 
> JSON or YAML format, for easy consumption by your code: aria services 
> show myservice --json. Note that you can also wrap ARIA's CLI in an HTTP 
> service.
> 3) You can access the database directly. ARIA uses a a normalized 
> relational (SQL) database.
>
> There are some challenges and limitations to each approach. If you 
> tell us what you're going to do we can help you move along in that direction.
>
>
> On Fri, Nov 24, 2017 at 7:37 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi Team,
> >
> > We are looking at an execution point during a service execution 
> > through a plugin. With this the execution will not go through the 
> > workflow runner
> > (install/uninstall) defined by the orchestrator but the services 
> > instance context object will be provided to the plugin which will 
> > take care of the complete service-execution.
> > This plugin is looked upon as a "service plugin" which will get the 
> > entire service model object and will provide the details to the 
> > external workflow engine.
> > We need this feature to enable the execution of workflows which some 
> > of our users already have. Please let us know your thoughts on this 
> > as we have already started our technical study on this.
> >
> >
> > Regards,
> > DJ
> >
>

Re: retiring/removal of committers

[Jakob Homan]

This was an explanation I had previously sent to another podling I mentor:


(Merit never expiring)  is not a bug.  As ASF sees it, this is a feature:
https://www.apache.org/dev/committers.html (search for Merit Never
Expires, an ASF axiom).  As a volunteer organization, we cannot
require anyone to do anything on any time frame.  Inactive committers
are in no way a drag on the community.  Instead they are a resource
that can often be activated when needed with a simple ping.  By virtue
of having been elected committers or PMCers, they are trusted to know
when and how to engage with the community when they are able to and in
such a way that keeps it healthy.  For example, if you've not been
active for a year, suddenly showing up and +1ing a megabyte patch in a
bit of code you were never involved in would be a jerk thing to do and
committers are trusted not to be jerks.  A very large pool of
committers, of varying activity and contribution is the goal here -
not a tight, exclusionary group of focused (probably paid) 10x-ers...

-Jakob

On 29 November 2017 at 14:42, John D. Ament  wrote:
> There is one out.  When a podling graduates, its customary to keep everyone
> on.  However, if there are people who are no longer interested in the
> project and the project chooses to not include them, its not uncommon that
> they be left off the graduation.  They would still be open to be included
> later on if they contribute once again.
>
> John
>
> On Wed, Nov 29, 2017 at 4:26 PM Thomas Nadeau  wrote:
>
>>
>> I think that is why we were having it - no one knew about Apache’s
>> rules around this.
>> That seems to settle the matter: once you are in, you are in.
>>
>> —Tom
>>
>>
>> > On Nov 29, 2017, at 3:42 PM, Suneel Marthi 
>> wrote:
>> >
>> > Fyi... committership never expires in ASF, unless the committer chooses
>> to
>> > go Emeritus. So not sure if this discussion is needed.
>> >
>> > On Wed, Nov 29, 2017 at 3:23 PM, Thomas Nadeau 
>> > wrote:
>> >
>> >>
>> >>One action I took from the last grooming meeting was to
>> >> investigate with the community, what process and policies we want to use
>> >> around the retirement and/or removal of Committers on the project. As
>> our
>> >> mentors have told us before, the community here is empowered to decide
>> the
>> >> criteria for how people are voted as committers, and the implication is
>> >> that the reverse is true too. However, after discussing this on our call
>> >> this week, it doesn’t seem there is any criteria defined; therefore, I
>> >> wanted to open up the discussion on this.
>> >>
>> >>To start, The Apache PMC guide says this about removal of
>> >> Committers/PMC members:
>> >>
>> >> [http://www.apache.org/dev/pmc.html#pmc-removal <
>> >> http://www.apache.org/dev/pmc.html#pmc-removal>]
>> >>
>> >> Projects can establish their own policy on handling inactive members, as
>> >> long as it is applied consistently.
>> >>
>> >> It is not a problem to retain members of the PMC who have become
>> inactive,
>> >> and it can make it easier for them to stay in touch with the project if
>> >> they choose to become active again.
>> >>
>> >> Typically, PMC members who are no longer able to participate will resign
>> >> from the PMC. However, if a PMC chooses to remove one of its members
>> (i.e.
>> >> without that member's consent), then it must request the Board to make
>> that
>> >> decision (which is typically done with a resolution at the Board's next
>> >> meeting). The PMC chair should send and email to the board@ mailing
>> list
>> >> detailing the request for removal and the justification the PMC has for
>> >> that removal, and cc: the project's private@ list.
>> >>
>> >>
>> >>So with that in mind, it looks like we need to augment the
>> >> guidelines Tal started on the wiki [https://cwiki.apache.org/
>> >> confluence/display/ARIATOSCA/Becoming+a+Committer <
>> >>
>> https://cwiki.apache.org/confluence/display/ARIATOSCA/Becoming+a+Committer
>> >]
>> >> to include removal/retirement/inactive PMC/committers.
>> >> To get the ball rolling, I wanted to make some suggestions for
>> >> (de)selection criteria that I’ve used in other OSS projects:
>> >>
>> >>Open Daylight uses this process:
>> >>
>> >> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process <
>> >> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process>
>> >>
>> >>OPNFV uses this:
>> >>
>> >> https://wiki.opnfv.org/display/DEV/Committer+Removal <
>> >> https://wiki.opnfv.org/display/DEV/Committer+Removal>
>> >>
>> >>Basically the process everyone basically uses allows a current
>> >> committer to elect to step down and there is a simple, straight-forward
>> >> process for this.
>> >> In other cases its a little more than the obvious: if someone isn’t
>> >> contributing to the project for an obviously prolonged time and 

Podling Report Reminder - December 2017

[johndament]

Dear podling,

This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.

The board meeting is scheduled for Wed, 20 December 2017, 10:30 am PDT.
The report for your podling will form a part of the Incubator PMC
report. The Incubator PMC requires your report to be submitted 2 weeks
before the board meeting, to allow sufficient time for review and
submission (Wed, December 06).

Please submit your report with sufficient time to allow the Incubator
PMC, and subsequently board members to review and digest. Again, the
very latest you should submit your report is 2 weeks prior to the board
meeting.

Thanks,

The Apache Incubator PMC

Submitting your Report

--

Your report should contain the following:

*   Your project name
*   A brief description of your project, which assumes no knowledge of
the project or necessarily of its field
*   A list of the three most important issues to address in the move
towards graduation.
*   Any issues that the Incubator PMC or ASF Board might wish/need to be
aware of
*   How has the community developed since the last report
*   How has the project developed since the last report.
*   How does the podling rate their own maturity.

This should be appended to the Incubator Wiki page at:

https://wiki.apache.org/incubator/December2017

Note: This is manually populated. You may need to wait a little before
this page is created from a template.

Mentors
---

Mentors should review reports for their project(s) and sign them off on
the Incubator wiki page. Signing off reports shows that you are
following the project - projects that are not signed may raise alarms
for the Incubator PMC.

Incubator PMC

Re: problem using cloudify extension with dev branch

[Tal Liron]

Ah, the dreaded multi-repo problems that I so detest, and am trying to
avoid by having it all in one repo...

The issue is that you are using a newer version of aria-extension-cloudify
than what is supported by aria on PyPI. I suggest keeping the two versions
matching to avoid problems.

On Wed, Nov 29, 2017 at 5:03 PM, DeWayne Filppi  wrote:

> I worked around this by installing the cloudify extention using the
> --no-deps argument (to pip).
>
> On Wed, Nov 29, 2017 at 2:32 PM, DeWayne Filppi 
> wrote:
>
> > OK.  I guess I didn't provide enough context.  I installed the ARIA-1
> > branch of ARIA in order to pick up a bug fix I needed.  When attempting
> to
> > install aria-extension-cloudify, it complains that ariatosca 0.2.0 is
> > installed, and it proceeds to remove it.  So, the cloudify extension
> > deletes ARIA, apparently because it's looking for a different version of
> > it.  The full message:
> >
> > Installing collected packages: apache-ariatosca, aria-extension-cloudify
> > Found existing installation: apache-ariatosca 0.2.0
> > Uninstalling apache-ariatosca-0.2.0:
> > Successfully uninstalled apache-ariatosca-0.2.0
> > Running setup.py develop for apache-ariatosca
> > Complete output from command /home/vagrant/venv/bin/python -c "import
> > setuptools, tokenize;__file__='/home/vagrant/venv/src/apache-
> > ariatosca/setup.py';f=getattr(tokenize, 'open',
> > open)(__file__);code=f.read().replace('\r\n',
> > '\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
> > --prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1:
> > running develop
> > Checking .pth file support in /home/vagrant/.aria/plugins/
> > aria-extension-cloudify-4.1/lib/python2.7/site-packages
> > /home/vagrant/venv/bin/python -E -c pass
> > TEST FAILED: /home/vagrant/.aria/plugins/aria-extension-cloudify-4.1/
> lib/python2.7/site-packages
> > does NOT support .pth files
> > error: bad install directory or PYTHONPATH
> > Command "/home/vagrant/venv/bin/python -c "import setuptools,
> > tokenize;__file__='/home/vagrant/venv/src/apache-
> > ariatosca/setup.py';f=getattr(tokenize, 'open',
> > open)(__file__);code=f.read().replace('\r\n',
> > '\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
> > --prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1" failed
> > with error code 1 in /home/vagrant/venv/src/apache-ariatosca/
> > Could not install package: aria-extension-cloudify (Command
> > "/home/vagrant/venv/bin/python -c "import setuptools,
> > tokenize;__file__='/home/vagrant/venv/src/apache-
> > ariatosca/setup.py';f=getattr(tokenize, 'open',
> > open)(__file__);code=f.read().replace('\r\n',
> > '\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
> > --prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1" failed
> > with error code 1 in /home/vagrant/venv/src/apache-ariatosca/)
> >
> >
> > On Wed, Nov 29, 2017 at 11:13 AM, Tal Liron  wrote:
> >
> >> Sorry, hard to understand exactly what you're trying to do, what's
> >> "failing" etc.
> >>
> >> All I can gather from this is that you are installing something that
> >> requires "apache-ariatosca" but that is already installed, so it's
> >> removing
> >> it in order to upgrade. You stopped the log there.
> >>
> >> On Wed, Nov 29, 2017 at 1:08 PM, DeWayne Filppi 
> >> wrote:
> >>
> >> > I see the following when trying to install the cloudify extension with
> >> the
> >> > ARIA-1 branch:
> >> >
> >> > Installing collected packages: apache-ariatosca,
> aria-extension-cloudify
> >> > Found existing installation: apache-ariatosca 0.2.0
> >> > Uninstalling apache-ariatosca-0.2.0:
> >> >
> >> > Then it fails.
> >> >
> >>
> >
> >
>

Re: problem using cloudify extension with dev branch

[DeWayne Filppi]

I worked around this by installing the cloudify extention using the
--no-deps argument (to pip).

On Wed, Nov 29, 2017 at 2:32 PM, DeWayne Filppi  wrote:

> OK.  I guess I didn't provide enough context.  I installed the ARIA-1
> branch of ARIA in order to pick up a bug fix I needed.  When attempting to
> install aria-extension-cloudify, it complains that ariatosca 0.2.0 is
> installed, and it proceeds to remove it.  So, the cloudify extension
> deletes ARIA, apparently because it's looking for a different version of
> it.  The full message:
>
> Installing collected packages: apache-ariatosca, aria-extension-cloudify
> Found existing installation: apache-ariatosca 0.2.0
> Uninstalling apache-ariatosca-0.2.0:
> Successfully uninstalled apache-ariatosca-0.2.0
> Running setup.py develop for apache-ariatosca
> Complete output from command /home/vagrant/venv/bin/python -c "import
> setuptools, tokenize;__file__='/home/vagrant/venv/src/apache-
> ariatosca/setup.py';f=getattr(tokenize, 'open',
> open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
> --prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1:
> running develop
> Checking .pth file support in /home/vagrant/.aria/plugins/
> aria-extension-cloudify-4.1/lib/python2.7/site-packages
> /home/vagrant/venv/bin/python -E -c pass
> TEST FAILED: 
> /home/vagrant/.aria/plugins/aria-extension-cloudify-4.1/lib/python2.7/site-packages
> does NOT support .pth files
> error: bad install directory or PYTHONPATH
> Command "/home/vagrant/venv/bin/python -c "import setuptools,
> tokenize;__file__='/home/vagrant/venv/src/apache-
> ariatosca/setup.py';f=getattr(tokenize, 'open',
> open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
> --prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1" failed
> with error code 1 in /home/vagrant/venv/src/apache-ariatosca/
> Could not install package: aria-extension-cloudify (Command
> "/home/vagrant/venv/bin/python -c "import setuptools,
> tokenize;__file__='/home/vagrant/venv/src/apache-
> ariatosca/setup.py';f=getattr(tokenize, 'open',
> open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
> --prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1" failed
> with error code 1 in /home/vagrant/venv/src/apache-ariatosca/)
>
>
> On Wed, Nov 29, 2017 at 11:13 AM, Tal Liron  wrote:
>
>> Sorry, hard to understand exactly what you're trying to do, what's
>> "failing" etc.
>>
>> All I can gather from this is that you are installing something that
>> requires "apache-ariatosca" but that is already installed, so it's
>> removing
>> it in order to upgrade. You stopped the log there.
>>
>> On Wed, Nov 29, 2017 at 1:08 PM, DeWayne Filppi 
>> wrote:
>>
>> > I see the following when trying to install the cloudify extension with
>> the
>> > ARIA-1 branch:
>> >
>> > Installing collected packages: apache-ariatosca, aria-extension-cloudify
>> > Found existing installation: apache-ariatosca 0.2.0
>> > Uninstalling apache-ariatosca-0.2.0:
>> >
>> > Then it fails.
>> >
>>
>
>

Re: retiring/removal of committers

[John D. Ament]

There is one out.  When a podling graduates, its customary to keep everyone
on.  However, if there are people who are no longer interested in the
project and the project chooses to not include them, its not uncommon that
they be left off the graduation.  They would still be open to be included
later on if they contribute once again.

John

On Wed, Nov 29, 2017 at 4:26 PM Thomas Nadeau  wrote:

>
> I think that is why we were having it - no one knew about Apache’s
> rules around this.
> That seems to settle the matter: once you are in, you are in.
>
> —Tom
>
>
> > On Nov 29, 2017, at 3:42 PM, Suneel Marthi 
> wrote:
> >
> > Fyi... committership never expires in ASF, unless the committer chooses
> to
> > go Emeritus. So not sure if this discussion is needed.
> >
> > On Wed, Nov 29, 2017 at 3:23 PM, Thomas Nadeau 
> > wrote:
> >
> >>
> >>One action I took from the last grooming meeting was to
> >> investigate with the community, what process and policies we want to use
> >> around the retirement and/or removal of Committers on the project. As
> our
> >> mentors have told us before, the community here is empowered to decide
> the
> >> criteria for how people are voted as committers, and the implication is
> >> that the reverse is true too. However, after discussing this on our call
> >> this week, it doesn’t seem there is any criteria defined; therefore, I
> >> wanted to open up the discussion on this.
> >>
> >>To start, The Apache PMC guide says this about removal of
> >> Committers/PMC members:
> >>
> >> [http://www.apache.org/dev/pmc.html#pmc-removal <
> >> http://www.apache.org/dev/pmc.html#pmc-removal>]
> >>
> >> Projects can establish their own policy on handling inactive members, as
> >> long as it is applied consistently.
> >>
> >> It is not a problem to retain members of the PMC who have become
> inactive,
> >> and it can make it easier for them to stay in touch with the project if
> >> they choose to become active again.
> >>
> >> Typically, PMC members who are no longer able to participate will resign
> >> from the PMC. However, if a PMC chooses to remove one of its members
> (i.e.
> >> without that member's consent), then it must request the Board to make
> that
> >> decision (which is typically done with a resolution at the Board's next
> >> meeting). The PMC chair should send and email to the board@ mailing
> list
> >> detailing the request for removal and the justification the PMC has for
> >> that removal, and cc: the project's private@ list.
> >>
> >>
> >>So with that in mind, it looks like we need to augment the
> >> guidelines Tal started on the wiki [https://cwiki.apache.org/
> >> confluence/display/ARIATOSCA/Becoming+a+Committer <
> >>
> https://cwiki.apache.org/confluence/display/ARIATOSCA/Becoming+a+Committer
> >]
> >> to include removal/retirement/inactive PMC/committers.
> >> To get the ball rolling, I wanted to make some suggestions for
> >> (de)selection criteria that I’ve used in other OSS projects:
> >>
> >>Open Daylight uses this process:
> >>
> >> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process <
> >> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process>
> >>
> >>OPNFV uses this:
> >>
> >> https://wiki.opnfv.org/display/DEV/Committer+Removal <
> >> https://wiki.opnfv.org/display/DEV/Committer+Removal>
> >>
> >>Basically the process everyone basically uses allows a current
> >> committer to elect to step down and there is a simple, straight-forward
> >> process for this.
> >> In other cases its a little more than the obvious: if someone isn’t
> >> contributing to the project for an obviously prolonged time and hasn’t
> >> verified they’re on a leave of absence or something, then they are
> simply
> >> notified with some notice to respond after which they are removed.
>  All of
> >> the examples also have solutions to more dire situations, but I’ve
> >> literally never seen that happen in any project I’ve worked on in like 6
> >> years.
> >>
> >>I’d like to propose a simple copy/paste of the OPNFV rules which
> >> seem to cover what is needed except for obviously changing the mailing
> >> list/TSC contacts.  We need to change “TSC” to “AriaTosca PPMC”.  There
> are
> >> things to clean up in there too like references to IRC - Apache requires
> >> everything to be on the dev mailer officially.
> >>
> >>—Tom
> >>
> >>
> >>
> >>
> >>
>
>

Re: problem using cloudify extension with dev branch

[DeWayne Filppi]

OK.  I guess I didn't provide enough context.  I installed the ARIA-1
branch of ARIA in order to pick up a bug fix I needed.  When attempting to
install aria-extension-cloudify, it complains that ariatosca 0.2.0 is
installed, and it proceeds to remove it.  So, the cloudify extension
deletes ARIA, apparently because it's looking for a different version of
it.  The full message:

Installing collected packages: apache-ariatosca, aria-extension-cloudify
Found existing installation: apache-ariatosca 0.2.0
Uninstalling apache-ariatosca-0.2.0:
Successfully uninstalled apache-ariatosca-0.2.0
Running setup.py develop for apache-ariatosca
Complete output from command /home/vagrant/venv/bin/python -c "import
setuptools,
tokenize;__file__='/home/vagrant/venv/src/apache-ariatosca/setup.py';f=getattr(tokenize,
'open', open)(__file__);code=f.read().replace('\r\n',
'\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
--prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1:
running develop
Checking .pth file support in
/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1/lib/python2.7/site-packages
/home/vagrant/venv/bin/python -E -c pass
TEST FAILED:
/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1/lib/python2.7/site-packages
does NOT support .pth files
error: bad install directory or PYTHONPATH
Command "/home/vagrant/venv/bin/python -c "import setuptools,
tokenize;__file__='/home/vagrant/venv/src/apache-ariatosca/setup.py';f=getattr(tokenize,
'open', open)(__file__);code=f.read().replace('\r\n',
'\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
--prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1" failed
with error code 1 in /home/vagrant/venv/src/apache-ariatosca/
Could not install package: aria-extension-cloudify (Command
"/home/vagrant/venv/bin/python -c "import setuptools,
tokenize;__file__='/home/vagrant/venv/src/apache-ariatosca/setup.py';f=getattr(tokenize,
'open', open)(__file__);code=f.read().replace('\r\n',
'\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
--prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1" failed
with error code 1 in /home/vagrant/venv/src/apache-ariatosca/)


On Wed, Nov 29, 2017 at 11:13 AM, Tal Liron  wrote:

> Sorry, hard to understand exactly what you're trying to do, what's
> "failing" etc.
>
> All I can gather from this is that you are installing something that
> requires "apache-ariatosca" but that is already installed, so it's removing
> it in order to upgrade. You stopped the log there.
>
> On Wed, Nov 29, 2017 at 1:08 PM, DeWayne Filppi 
> wrote:
>
> > I see the following when trying to install the cloudify extension with
> the
> > ARIA-1 branch:
> >
> > Installing collected packages: apache-ariatosca, aria-extension-cloudify
> > Found existing installation: apache-ariatosca 0.2.0
> > Uninstalling apache-ariatosca-0.2.0:
> >
> > Then it fails.
> >
>

Re: retiring/removal of committers

[Thomas Nadeau]

I think that is why we were having it - no one knew about Apache’s 
rules around this.
That seems to settle the matter: once you are in, you are in.

—Tom


> On Nov 29, 2017, at 3:42 PM, Suneel Marthi  wrote:
> 
> Fyi... committership never expires in ASF, unless the committer chooses to
> go Emeritus. So not sure if this discussion is needed.
> 
> On Wed, Nov 29, 2017 at 3:23 PM, Thomas Nadeau 
> wrote:
> 
>> 
>>One action I took from the last grooming meeting was to
>> investigate with the community, what process and policies we want to use
>> around the retirement and/or removal of Committers on the project. As our
>> mentors have told us before, the community here is empowered to decide the
>> criteria for how people are voted as committers, and the implication is
>> that the reverse is true too. However, after discussing this on our call
>> this week, it doesn’t seem there is any criteria defined; therefore, I
>> wanted to open up the discussion on this.
>> 
>>To start, The Apache PMC guide says this about removal of
>> Committers/PMC members:
>> 
>> [http://www.apache.org/dev/pmc.html#pmc-removal <
>> http://www.apache.org/dev/pmc.html#pmc-removal>]
>> 
>> Projects can establish their own policy on handling inactive members, as
>> long as it is applied consistently.
>> 
>> It is not a problem to retain members of the PMC who have become inactive,
>> and it can make it easier for them to stay in touch with the project if
>> they choose to become active again.
>> 
>> Typically, PMC members who are no longer able to participate will resign
>> from the PMC. However, if a PMC chooses to remove one of its members (i.e.
>> without that member's consent), then it must request the Board to make that
>> decision (which is typically done with a resolution at the Board's next
>> meeting). The PMC chair should send and email to the board@ mailing list
>> detailing the request for removal and the justification the PMC has for
>> that removal, and cc: the project's private@ list.
>> 
>> 
>>So with that in mind, it looks like we need to augment the
>> guidelines Tal started on the wiki [https://cwiki.apache.org/
>> confluence/display/ARIATOSCA/Becoming+a+Committer <
>> https://cwiki.apache.org/confluence/display/ARIATOSCA/Becoming+a+Committer>]
>> to include removal/retirement/inactive PMC/committers.
>> To get the ball rolling, I wanted to make some suggestions for
>> (de)selection criteria that I’ve used in other OSS projects:
>> 
>>Open Daylight uses this process:
>> 
>> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process <
>> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process>
>> 
>>OPNFV uses this:
>> 
>> https://wiki.opnfv.org/display/DEV/Committer+Removal <
>> https://wiki.opnfv.org/display/DEV/Committer+Removal>
>> 
>>Basically the process everyone basically uses allows a current
>> committer to elect to step down and there is a simple, straight-forward
>> process for this.
>> In other cases its a little more than the obvious: if someone isn’t
>> contributing to the project for an obviously prolonged time and hasn’t
>> verified they’re on a leave of absence or something, then they are simply
>> notified with some notice to respond after which they are removed.   All of
>> the examples also have solutions to more dire situations, but I’ve
>> literally never seen that happen in any project I’ve worked on in like 6
>> years.
>> 
>>I’d like to propose a simple copy/paste of the OPNFV rules which
>> seem to cover what is needed except for obviously changing the mailing
>> list/TSC contacts.  We need to change “TSC” to “AriaTosca PPMC”.  There are
>> things to clean up in there too like references to IRC - Apache requires
>> everything to be on the dev mailer officially.
>> 
>>—Tom
>> 
>> 
>> 
>> 
>> 

Re: retiring/removal of committers

[Suneel Marthi]

Fyi... committership never expires in ASF, unless the committer chooses to
go Emeritus. So not sure if this discussion is needed.

On Wed, Nov 29, 2017 at 3:23 PM, Thomas Nadeau 
wrote:

>
> One action I took from the last grooming meeting was to
> investigate with the community, what process and policies we want to use
> around the retirement and/or removal of Committers on the project. As our
> mentors have told us before, the community here is empowered to decide the
> criteria for how people are voted as committers, and the implication is
> that the reverse is true too. However, after discussing this on our call
> this week, it doesn’t seem there is any criteria defined; therefore, I
> wanted to open up the discussion on this.
>
> To start, The Apache PMC guide says this about removal of
> Committers/PMC members:
>
> [http://www.apache.org/dev/pmc.html#pmc-removal <
> http://www.apache.org/dev/pmc.html#pmc-removal>]
>
> Projects can establish their own policy on handling inactive members, as
> long as it is applied consistently.
>
> It is not a problem to retain members of the PMC who have become inactive,
> and it can make it easier for them to stay in touch with the project if
> they choose to become active again.
>
> Typically, PMC members who are no longer able to participate will resign
> from the PMC. However, if a PMC chooses to remove one of its members (i.e.
> without that member's consent), then it must request the Board to make that
> decision (which is typically done with a resolution at the Board's next
> meeting). The PMC chair should send and email to the board@ mailing list
> detailing the request for removal and the justification the PMC has for
> that removal, and cc: the project's private@ list.
>
>
> So with that in mind, it looks like we need to augment the
> guidelines Tal started on the wiki [https://cwiki.apache.org/
> confluence/display/ARIATOSCA/Becoming+a+Committer <
> https://cwiki.apache.org/confluence/display/ARIATOSCA/Becoming+a+Committer>]
> to include removal/retirement/inactive PMC/committers.
> To get the ball rolling, I wanted to make some suggestions for
> (de)selection criteria that I’ve used in other OSS projects:
>
> Open Daylight uses this process:
>
> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process <
> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process>
>
> OPNFV uses this:
>
> https://wiki.opnfv.org/display/DEV/Committer+Removal <
> https://wiki.opnfv.org/display/DEV/Committer+Removal>
>
> Basically the process everyone basically uses allows a current
> committer to elect to step down and there is a simple, straight-forward
> process for this.
> In other cases its a little more than the obvious: if someone isn’t
> contributing to the project for an obviously prolonged time and hasn’t
> verified they’re on a leave of absence or something, then they are simply
> notified with some notice to respond after which they are removed.   All of
> the examples also have solutions to more dire situations, but I’ve
> literally never seen that happen in any project I’ve worked on in like 6
> years.
>
> I’d like to propose a simple copy/paste of the OPNFV rules which
> seem to cover what is needed except for obviously changing the mailing
> list/TSC contacts.  We need to change “TSC” to “AriaTosca PPMC”.  There are
> things to clean up in there too like references to IRC - Apache requires
> everything to be on the dev mailer officially.
>
> —Tom
>
>
>
>
>

retiring/removal of committers

[Thomas Nadeau]

One action I took from the last grooming meeting was to investigate 
with the community, what process and policies we want to use around the 
retirement and/or removal of Committers on the project. As our mentors have 
told us before, the community here is empowered to decide the criteria for how 
people are voted as committers, and the implication is that the reverse is true 
too. However, after discussing this on our call this week, it doesn’t seem 
there is any criteria defined; therefore, I wanted to open up the discussion on 
this. 

To start, The Apache PMC guide says this about removal of 
Committers/PMC members:

[http://www.apache.org/dev/pmc.html#pmc-removal 
]

Projects can establish their own policy on handling inactive members, as long 
as it is applied consistently.

It is not a problem to retain members of the PMC who have become inactive, and 
it can make it easier for them to stay in touch with the project if they choose 
to become active again.

Typically, PMC members who are no longer able to participate will resign from 
the PMC. However, if a PMC chooses to remove one of its members (i.e. without 
that member's consent), then it must request the Board to make that decision 
(which is typically done with a resolution at the Board's next meeting). The 
PMC chair should send and email to the board@ mailing list detailing the 
request for removal and the justification the PMC has for that removal, and cc: 
the project's private@ list.


So with that in mind, it looks like we need to augment the guidelines 
Tal started on the wiki 
[https://cwiki.apache.org/confluence/display/ARIATOSCA/Becoming+a+Committer 
] 
to include removal/retirement/inactive PMC/committers.
To get the ball rolling, I wanted to make some suggestions for (de)selection 
criteria that I’ve used in other OSS projects:

Open Daylight uses this process:

https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process 


OPNFV uses this:

https://wiki.opnfv.org/display/DEV/Committer+Removal 


Basically the process everyone basically uses allows a current 
committer to elect to step down and there is a simple, straight-forward process 
for this.
In other cases its a little more than the obvious: if someone isn’t 
contributing to the project for an obviously prolonged time and hasn’t verified 
they’re on a leave of absence or something, then they are simply notified with 
some notice to respond after which they are removed.   All of the examples also 
have solutions to more dire situations, but I’ve literally never seen that 
happen in any project I’ve worked on in like 6 years. 

I’d like to propose a simple copy/paste of the OPNFV rules which seem 
to cover what is needed except for obviously changing the mailing list/TSC 
contacts.  We need to change “TSC” to “AriaTosca PPMC”.  There are things to 
clean up in there too like references to IRC - Apache requires everything to be 
on the dev mailer officially.

—Tom
 

Re: problem using cloudify extension with dev branch

[Tal Liron]

Sorry, hard to understand exactly what you're trying to do, what's
"failing" etc.

All I can gather from this is that you are installing something that
requires "apache-ariatosca" but that is already installed, so it's removing
it in order to upgrade. You stopped the log there.

On Wed, Nov 29, 2017 at 1:08 PM, DeWayne Filppi  wrote:

> I see the following when trying to install the cloudify extension with the
> ARIA-1 branch:
>
> Installing collected packages: apache-ariatosca, aria-extension-cloudify
> Found existing installation: apache-ariatosca 0.2.0
> Uninstalling apache-ariatosca-0.2.0:
>
> Then it fails.
>