Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-17 Thread Tony Breeds
On Wed, Feb 17, 2016 at 06:58:18PM -0500, Sean Dague wrote:
> On 02/17/2016 05:05 PM, Doug Hellmann wrote:
> > Excerpts from Tony Breeds's message of 2016-02-18 08:04:00 +1100:
> 
> >> I think we're in a tough spot.
> >>
> >> My $0.02 is that we have to cap at <0.18.0 however 
> >>
> >> We're (the openstack community) finding issues with eventlet which is good
> >> (painful I agree, but good) for both communities.  However we *are* trying 
> >> to
> >> lock down our release, and test/gate failures are very unwelcome in this
> >> phase.
> >>
> >> 0.18.2 was "mostly" good but shows the following bug:
> >>   https://bugs.launchpad.net/nova/+bug/1544801
> >>
> >> The eventlet team have been very responsive to our issue reports.  I'm 
> >> worried
> >> if we cap at 0.18.2 (or 0.17.4) the underlying problems will go undressed 
> >> and
> >> unnoticed for too long and then we'll all loose :(  Not least of all 
> >> because
> >> it's *very* likely if we cap this we'll release with the cap which means 
> >> we're
> >> basically stuck with it for the whole life-cycle of mitaka[1][2]
> > 
> > The current plan is to not cap, but exclude the bad versions. The patch
> > to do that (https://review.openstack.org/#/c/281479/) does set the
> > constraint to 0.18.2, so if we need to change that please drop a comment
> > on the review.
> > 
> >> Calls for "extra vetting" of new eventlet releases are slightly 
> >> problematic,
> >> and really require a short cross-project team to verify, as the "Yup is 
> >> passes
> >> dsvm-tempest-full" doesn't cut it.
> > 
> > Can we construct a better automated test scenario?
> 
> Question. Are we only tripping this up in unit tests because the tests
> are doing things we'd never really do in real life?

In the case of (nova):
 https://bugs.launchpad.net/nova/+bug/1544801
 https://github.com/eventlet/eventlet/issues/299

It was seen in a "in the wild".  That particular issue didn't seem to break
anything (for nova) but did record lots of tracebacks in logs.

The keystone failure with 0.18.2 *was* limited to tests and has been worked
around for the time being.
  https://github.com/eventlet/eventlet/issues/296

The Neutron issue:
  https://bugs.launchpad.net/neutron/+bug/1546506
  https://github.com/eventlet/eventlet/issues/301

I don't think this was a test-only scenario, and was a clear regression between
0.18.3 and 0.18.3

In my opinion we'll need something to increase faith in a new release, be that
manual effort or better tests/tools

The challenge seems to be getting back to a point where we can function.

I suggested moving back to 0.17.4, but that's going to be hard[1] as we've made
several library releases that have "evelntlet>=0.18.2"

So perhaps [2] is the right thing to do, as it was mostly good.  I think we can
deal with the log spam while we test 0.18.4

Like I said earlier the eventlet team has been very responsive and I'm
certainly not ignoring that.  We just need to be confident that whichever
approach we take we can complete it my R-5

> For instance, the nova bug was because someone decided to test the
> eventlet wsgi server with a sample app with a custom written eventlet
> http client that was doing raw socket reads naively. Which was never a
> good idea. The fix: use requests as our http client. Life was fine.

Yeah, there have certainly been some test-only issues.

> I think it's fine if we're going to want some better tests for bumping
> upper-constraints.txt, even if it's tests we only run for certain touchy
> packages like eventlet. However we should make sure it wasn't just our
> tests being kind of bonkers.

I *think* we've passed the point where we're seeing issues restricted to the
unit/functional/tempest tests.

Yours Tony.

[1] https://review.openstack.org/#/c/281479/2
[2] https://review.openstack.org/#/c/281479/1


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-17 Thread David Stanek
On Wed, Feb 17, 2016 at 6:58 PM Sean Dague  wrote:

>
> Question. Are we only tripping this up in unit tests because the tests
> are doing things we'd never really do in real life?
>

I think that some of the issues have been real. Keystone had issues with
0.18.0 because it dropped methods from subprocess after patching it. They
called it out in their release notes as an incompatible change.

Version 0.18.2 broke the Keystone tests for Python 34. The poll() method
seemed to be in some sort of deadlock and the tests timed out. This may
have been a testing problem, but for whatever reason Python27 didn't have
the issue.

I want to say that we've seen other issues after 0.17.4, but I can't find
definitive evidence.

-- David
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-17 Thread Sean Dague
On 02/17/2016 05:05 PM, Doug Hellmann wrote:
> Excerpts from Tony Breeds's message of 2016-02-18 08:04:00 +1100:

>> I think we're in a tough spot.
>>
>> My $0.02 is that we have to cap at <0.18.0 however 
>>
>> We're (the openstack community) finding issues with eventlet which is good
>> (painful I agree, but good) for both communities.  However we *are* trying to
>> lock down our release, and test/gate failures are very unwelcome in this
>> phase.
>>
>> 0.18.2 was "mostly" good but shows the following bug:
>>   https://bugs.launchpad.net/nova/+bug/1544801
>>
>> The eventlet team have been very responsive to our issue reports.  I'm 
>> worried
>> if we cap at 0.18.2 (or 0.17.4) the underlying problems will go undressed and
>> unnoticed for too long and then we'll all loose :(  Not least of all because
>> it's *very* likely if we cap this we'll release with the cap which means 
>> we're
>> basically stuck with it for the whole life-cycle of mitaka[1][2]
> 
> The current plan is to not cap, but exclude the bad versions. The patch
> to do that (https://review.openstack.org/#/c/281479/) does set the
> constraint to 0.18.2, so if we need to change that please drop a comment
> on the review.
> 
>> Calls for "extra vetting" of new eventlet releases are slightly problematic,
>> and really require a short cross-project team to verify, as the "Yup is 
>> passes
>> dsvm-tempest-full" doesn't cut it.
> 
> Can we construct a better automated test scenario?

Question. Are we only tripping this up in unit tests because the tests
are doing things we'd never really do in real life?

For instance, the nova bug was because someone decided to test the
eventlet wsgi server with a sample app with a custom written eventlet
http client that was doing raw socket reads naively. Which was never a
good idea. The fix: use requests as our http client. Life was fine.

I think it's fine if we're going to want some better tests for bumping
upper-constraints.txt, even if it's tests we only run for certain touchy
packages like eventlet. However we should make sure it wasn't just our
tests being kind of bonkers.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-17 Thread Doug Hellmann
Excerpts from Tony Breeds's message of 2016-02-18 08:04:00 +1100:
> On Wed, Feb 17, 2016 at 12:44:11PM -0500, Doug Hellmann wrote:
> > Excerpts from Henry Gessau's message of 2016-02-17 11:00:53 -0500:
> > > Doug Hellmann  wrote:
> > > > Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800:
> > > >> On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague  wrote:
> > > >>
> > > >>> On 02/17/2016 08:42 AM, Doug Hellmann wrote:
> > >  Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100:
> > > > Le 17/02/2016 13:43, Henry Gessau a écrit :
> > > >> And it looks like eventlet 0.18.3 breaks neutron:
> > > >> https://bugs.launchpad.net/neutron/+bug/1546506
> > > >
> > > > 2 releases, 2 regressions in OpenStack. Should we cap eventlet 
> > > > version?
> > > > The requirement bot can produce patches to update eventlet, patches
> > > > which would run integration tests using Nova, Keystone, Neutron on 
> > > > the
> > > > new eventlet version.
> > > >
> > > > eventlet 0.18.2 broke OpenStack Keystone and OpenStack Nova
> > > > https://github.com/eventlet/eventlet/issues/296
> > > > https://github.com/eventlet/eventlet/issues/299
> > > > https://review.openstack.org/#/c/278147/
> > > > https://bugs.launchpad.net/nova/+bug/1544801
> > > >
> > > > eventlet 0.18.3 broke OpenStack Neutron
> > > > https://github.com/eventlet/eventlet/issues/301
> > > > https://bugs.launchpad.net/neutron/+bug/1546506
> > > >
> > > > FYI eventlet 0.18.0 broke WSGI servers:
> > > > https://github.com/eventlet/eventlet/issues/295
> > > >
> > > > It was followed quickly by eventlet 0.18.2 to fix this issue.
> > > >
> > > > Sadly, it looks like bugfix releases of eventlet don't include a 
> > > > single
> > > > bugfix, but include also other changes. For example, 0.18.3 fixed 
> > > > the
> > > > bug #296 but introduced "wsgi: TCP_NODELAY enabled by default"
> > > >>> optimization.
> > > >
> > > > IMHO the problem is not the release manager of eventlet, but more 
> > > > the
> > > > lack of tests on eventlet, especially on OpenStack services.
> > > >
> > > > Current "Continious Delivery"-like with gates do detect bugs, yeah, 
> > > > but
> > > > also block a lot of developers when the gates are broken. It doesn't
> > > > seem trivial to investigate and fix eventlet issues.
> > > >
> > > > Victor
> > > >
> > > 
> > >  Whether we cap or not, we should exclude the known broken versions.
> > >  It looks like getting back to a good version will also require
> > >  lowering the minimum version we support, since we have >=0.18.2
> > >  now.
> > > 
> > >  What was the last version of eventlet known to work?
> > > >>>
> > > >>> 0.18.2 works. On the Nova side we had a failure around unit tests 
> > > >>> which
> > > >>> was quite synthetic that we fixed. I don' know what the keystone issue
> > > >>> turned out to be.
> > > >>>
> > > >>
> > > >> I believe the keystone issue was a test specific issue, not a runtime
> > > >> issue. We disabled the test.
> > > >> --Morgan
> > > > 
> > > > OK. Can someone from the neutron team verify that 0.18.2 works? If so,
> > > > we can just exclude 0.18.3 and reset the constraint.
> > > 
> > > I can confirm that neutron works with 0.18.2 as far as we know.
> > > 
> > 
> > Great. If you (or someone else) wants to submit a requirements update, I
> > can approve it. Ping me in #openstack-release.
> 
> I think we're in a tough spot.
> 
> My $0.02 is that we have to cap at <0.18.0 however 
> 
> We're (the openstack community) finding issues with eventlet which is good
> (painful I agree, but good) for both communities.  However we *are* trying to
> lock down our release, and test/gate failures are very unwelcome in this
> phase.
> 
> 0.18.2 was "mostly" good but shows the following bug:
>   https://bugs.launchpad.net/nova/+bug/1544801
> 
> The eventlet team have been very responsive to our issue reports.  I'm worried
> if we cap at 0.18.2 (or 0.17.4) the underlying problems will go undressed and
> unnoticed for too long and then we'll all loose :(  Not least of all because
> it's *very* likely if we cap this we'll release with the cap which means we're
> basically stuck with it for the whole life-cycle of mitaka[1][2]

The current plan is to not cap, but exclude the bad versions. The patch
to do that (https://review.openstack.org/#/c/281479/) does set the
constraint to 0.18.2, so if we need to change that please drop a comment
on the review.

> Calls for "extra vetting" of new eventlet releases are slightly problematic,
> and really require a short cross-project team to verify, as the "Yup is passes
> dsvm-tempest-full" doesn't cut it.

Can we construct a better automated test scenario?

Doug

> 
> Yours Tony.
> 
> [1] Given we're @ R-7 and requirements freeze is 

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-17 Thread Tony Breeds
On Wed, Feb 17, 2016 at 12:44:11PM -0500, Doug Hellmann wrote:
> Excerpts from Henry Gessau's message of 2016-02-17 11:00:53 -0500:
> > Doug Hellmann  wrote:
> > > Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800:
> > >> On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague  wrote:
> > >>
> > >>> On 02/17/2016 08:42 AM, Doug Hellmann wrote:
> >  Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100:
> > > Le 17/02/2016 13:43, Henry Gessau a écrit :
> > >> And it looks like eventlet 0.18.3 breaks neutron:
> > >> https://bugs.launchpad.net/neutron/+bug/1546506
> > >
> > > 2 releases, 2 regressions in OpenStack. Should we cap eventlet 
> > > version?
> > > The requirement bot can produce patches to update eventlet, patches
> > > which would run integration tests using Nova, Keystone, Neutron on the
> > > new eventlet version.
> > >
> > > eventlet 0.18.2 broke OpenStack Keystone and OpenStack Nova
> > > https://github.com/eventlet/eventlet/issues/296
> > > https://github.com/eventlet/eventlet/issues/299
> > > https://review.openstack.org/#/c/278147/
> > > https://bugs.launchpad.net/nova/+bug/1544801
> > >
> > > eventlet 0.18.3 broke OpenStack Neutron
> > > https://github.com/eventlet/eventlet/issues/301
> > > https://bugs.launchpad.net/neutron/+bug/1546506
> > >
> > > FYI eventlet 0.18.0 broke WSGI servers:
> > > https://github.com/eventlet/eventlet/issues/295
> > >
> > > It was followed quickly by eventlet 0.18.2 to fix this issue.
> > >
> > > Sadly, it looks like bugfix releases of eventlet don't include a 
> > > single
> > > bugfix, but include also other changes. For example, 0.18.3 fixed the
> > > bug #296 but introduced "wsgi: TCP_NODELAY enabled by default"
> > >>> optimization.
> > >
> > > IMHO the problem is not the release manager of eventlet, but more the
> > > lack of tests on eventlet, especially on OpenStack services.
> > >
> > > Current "Continious Delivery"-like with gates do detect bugs, yeah, 
> > > but
> > > also block a lot of developers when the gates are broken. It doesn't
> > > seem trivial to investigate and fix eventlet issues.
> > >
> > > Victor
> > >
> > 
> >  Whether we cap or not, we should exclude the known broken versions.
> >  It looks like getting back to a good version will also require
> >  lowering the minimum version we support, since we have >=0.18.2
> >  now.
> > 
> >  What was the last version of eventlet known to work?
> > >>>
> > >>> 0.18.2 works. On the Nova side we had a failure around unit tests which
> > >>> was quite synthetic that we fixed. I don' know what the keystone issue
> > >>> turned out to be.
> > >>>
> > >>
> > >> I believe the keystone issue was a test specific issue, not a runtime
> > >> issue. We disabled the test.
> > >> --Morgan
> > > 
> > > OK. Can someone from the neutron team verify that 0.18.2 works? If so,
> > > we can just exclude 0.18.3 and reset the constraint.
> > 
> > I can confirm that neutron works with 0.18.2 as far as we know.
> > 
> 
> Great. If you (or someone else) wants to submit a requirements update, I
> can approve it. Ping me in #openstack-release.

I think we're in a tough spot.

My $0.02 is that we have to cap at <0.18.0 however 

We're (the openstack community) finding issues with eventlet which is good
(painful I agree, but good) for both communities.  However we *are* trying to
lock down our release, and test/gate failures are very unwelcome in this
phase.

0.18.2 was "mostly" good but shows the following bug:
  https://bugs.launchpad.net/nova/+bug/1544801

The eventlet team have been very responsive to our issue reports.  I'm worried
if we cap at 0.18.2 (or 0.17.4) the underlying problems will go undressed and
unnoticed for too long and then we'll all loose :(  Not least of all because
it's *very* likely if we cap this we'll release with the cap which means we're
basically stuck with it for the whole life-cycle of mitaka[1][2]

Calls for "extra vetting" of new eventlet releases are slightly problematic,
and really require a short cross-project team to verify, as the "Yup is passes
dsvm-tempest-full" doesn't cut it.

Yours Tony.

[1] Given we're @ R-7 and requirements freeze is R-5
[2] Assuming we cap at <0.18.0, we don't generally allow raising the minimum
version of $library in a stable release


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-17 Thread Doug Hellmann
Excerpts from Henry Gessau's message of 2016-02-17 13:00:03 -0500:
> Doug Hellmann  wrote:
> > Excerpts from Henry Gessau's message of 2016-02-17 11:00:53 -0500:
> >> Doug Hellmann  wrote:
> >>> Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800:
>  On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague  wrote:
> 
> > On 02/17/2016 08:42 AM, Doug Hellmann wrote:
> >> Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100:
> >>> Le 17/02/2016 13:43, Henry Gessau a écrit :
>  And it looks like eventlet 0.18.3 breaks neutron:
>  https://bugs.launchpad.net/neutron/+bug/1546506
> >>>
> >>> 2 releases, 2 regressions in OpenStack. Should we cap eventlet 
> >>> version?
> >>> The requirement bot can produce patches to update eventlet, patches
> >>> which would run integration tests using Nova, Keystone, Neutron on the
> >>> new eventlet version.
> >>>
> >>> eventlet 0.18.2 broke OpenStack Keystone and OpenStack Nova
> >>> https://github.com/eventlet/eventlet/issues/296
> >>> https://github.com/eventlet/eventlet/issues/299
> >>> https://review.openstack.org/#/c/278147/
> >>> https://bugs.launchpad.net/nova/+bug/1544801
> >>>
> >>> eventlet 0.18.3 broke OpenStack Neutron
> >>> https://github.com/eventlet/eventlet/issues/301
> >>> https://bugs.launchpad.net/neutron/+bug/1546506
> >>>
> >>> FYI eventlet 0.18.0 broke WSGI servers:
> >>> https://github.com/eventlet/eventlet/issues/295
> >>>
> >>> It was followed quickly by eventlet 0.18.2 to fix this issue.
> >>>
> >>> Sadly, it looks like bugfix releases of eventlet don't include a 
> >>> single
> >>> bugfix, but include also other changes. For example, 0.18.3 fixed the
> >>> bug #296 but introduced "wsgi: TCP_NODELAY enabled by default"
> > optimization.
> >>>
> >>> IMHO the problem is not the release manager of eventlet, but more the
> >>> lack of tests on eventlet, especially on OpenStack services.
> >>>
> >>> Current "Continious Delivery"-like with gates do detect bugs, yeah, 
> >>> but
> >>> also block a lot of developers when the gates are broken. It doesn't
> >>> seem trivial to investigate and fix eventlet issues.
> >>>
> >>> Victor
> >>>
> >>
> >> Whether we cap or not, we should exclude the known broken versions.
> >> It looks like getting back to a good version will also require
> >> lowering the minimum version we support, since we have >=0.18.2
> >> now.
> >>
> >> What was the last version of eventlet known to work?
> >
> > 0.18.2 works. On the Nova side we had a failure around unit tests which
> > was quite synthetic that we fixed. I don' know what the keystone issue
> > turned out to be.
> >
> 
>  I believe the keystone issue was a test specific issue, not a runtime
>  issue. We disabled the test.
>  --Morgan
> >>>
> >>> OK. Can someone from the neutron team verify that 0.18.2 works? If so,
> >>> we can just exclude 0.18.3 and reset the constraint.
> >>
> >> I can confirm that neutron works with 0.18.2 as far as we know.
> >>
> > 
> > Great. If you (or someone else) wants to submit a requirements update, I
> > can approve it. Ping me in #openstack-release.
> 
> If it's only neutron that is affected by 0.18.3 then we already have our
> workaround in place [1]. Additionally, eventlet 0.18.4 will replace the
> breaking change with a different approach [2].

I suspect, given the phase of our cycle we're in and the nature of the
past couple of eventlet releases, we're going to want to do more
extensive testing before taking a new release. We're approaching a
requirements freeze *anyway* so it may be moot, depending on when they
get 0.18.4 out.

Doug

> 
> [1] https://review.openstack.org/281278
> [2] https://github.com/eventlet/eventlet/issues/301
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-17 Thread Henry Gessau
Doug Hellmann  wrote:
> Excerpts from Henry Gessau's message of 2016-02-17 11:00:53 -0500:
>> Doug Hellmann  wrote:
>>> Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800:
 On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague  wrote:

> On 02/17/2016 08:42 AM, Doug Hellmann wrote:
>> Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100:
>>> Le 17/02/2016 13:43, Henry Gessau a écrit :
 And it looks like eventlet 0.18.3 breaks neutron:
 https://bugs.launchpad.net/neutron/+bug/1546506
>>>
>>> 2 releases, 2 regressions in OpenStack. Should we cap eventlet version?
>>> The requirement bot can produce patches to update eventlet, patches
>>> which would run integration tests using Nova, Keystone, Neutron on the
>>> new eventlet version.
>>>
>>> eventlet 0.18.2 broke OpenStack Keystone and OpenStack Nova
>>> https://github.com/eventlet/eventlet/issues/296
>>> https://github.com/eventlet/eventlet/issues/299
>>> https://review.openstack.org/#/c/278147/
>>> https://bugs.launchpad.net/nova/+bug/1544801
>>>
>>> eventlet 0.18.3 broke OpenStack Neutron
>>> https://github.com/eventlet/eventlet/issues/301
>>> https://bugs.launchpad.net/neutron/+bug/1546506
>>>
>>> FYI eventlet 0.18.0 broke WSGI servers:
>>> https://github.com/eventlet/eventlet/issues/295
>>>
>>> It was followed quickly by eventlet 0.18.2 to fix this issue.
>>>
>>> Sadly, it looks like bugfix releases of eventlet don't include a single
>>> bugfix, but include also other changes. For example, 0.18.3 fixed the
>>> bug #296 but introduced "wsgi: TCP_NODELAY enabled by default"
> optimization.
>>>
>>> IMHO the problem is not the release manager of eventlet, but more the
>>> lack of tests on eventlet, especially on OpenStack services.
>>>
>>> Current "Continious Delivery"-like with gates do detect bugs, yeah, but
>>> also block a lot of developers when the gates are broken. It doesn't
>>> seem trivial to investigate and fix eventlet issues.
>>>
>>> Victor
>>>
>>
>> Whether we cap or not, we should exclude the known broken versions.
>> It looks like getting back to a good version will also require
>> lowering the minimum version we support, since we have >=0.18.2
>> now.
>>
>> What was the last version of eventlet known to work?
>
> 0.18.2 works. On the Nova side we had a failure around unit tests which
> was quite synthetic that we fixed. I don' know what the keystone issue
> turned out to be.
>

 I believe the keystone issue was a test specific issue, not a runtime
 issue. We disabled the test.
 --Morgan
>>>
>>> OK. Can someone from the neutron team verify that 0.18.2 works? If so,
>>> we can just exclude 0.18.3 and reset the constraint.
>>
>> I can confirm that neutron works with 0.18.2 as far as we know.
>>
> 
> Great. If you (or someone else) wants to submit a requirements update, I
> can approve it. Ping me in #openstack-release.

If it's only neutron that is affected by 0.18.3 then we already have our
workaround in place [1]. Additionally, eventlet 0.18.4 will replace the
breaking change with a different approach [2].

[1] https://review.openstack.org/281278
[2] https://github.com/eventlet/eventlet/issues/301


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-17 Thread Doug Hellmann
Excerpts from Henry Gessau's message of 2016-02-17 11:00:53 -0500:
> Doug Hellmann  wrote:
> > Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800:
> >> On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague  wrote:
> >>
> >>> On 02/17/2016 08:42 AM, Doug Hellmann wrote:
>  Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100:
> > Le 17/02/2016 13:43, Henry Gessau a écrit :
> >> And it looks like eventlet 0.18.3 breaks neutron:
> >> https://bugs.launchpad.net/neutron/+bug/1546506
> >
> > 2 releases, 2 regressions in OpenStack. Should we cap eventlet version?
> > The requirement bot can produce patches to update eventlet, patches
> > which would run integration tests using Nova, Keystone, Neutron on the
> > new eventlet version.
> >
> > eventlet 0.18.2 broke OpenStack Keystone and OpenStack Nova
> > https://github.com/eventlet/eventlet/issues/296
> > https://github.com/eventlet/eventlet/issues/299
> > https://review.openstack.org/#/c/278147/
> > https://bugs.launchpad.net/nova/+bug/1544801
> >
> > eventlet 0.18.3 broke OpenStack Neutron
> > https://github.com/eventlet/eventlet/issues/301
> > https://bugs.launchpad.net/neutron/+bug/1546506
> >
> > FYI eventlet 0.18.0 broke WSGI servers:
> > https://github.com/eventlet/eventlet/issues/295
> >
> > It was followed quickly by eventlet 0.18.2 to fix this issue.
> >
> > Sadly, it looks like bugfix releases of eventlet don't include a single
> > bugfix, but include also other changes. For example, 0.18.3 fixed the
> > bug #296 but introduced "wsgi: TCP_NODELAY enabled by default"
> >>> optimization.
> >
> > IMHO the problem is not the release manager of eventlet, but more the
> > lack of tests on eventlet, especially on OpenStack services.
> >
> > Current "Continious Delivery"-like with gates do detect bugs, yeah, but
> > also block a lot of developers when the gates are broken. It doesn't
> > seem trivial to investigate and fix eventlet issues.
> >
> > Victor
> >
> 
>  Whether we cap or not, we should exclude the known broken versions.
>  It looks like getting back to a good version will also require
>  lowering the minimum version we support, since we have >=0.18.2
>  now.
> 
>  What was the last version of eventlet known to work?
> >>>
> >>> 0.18.2 works. On the Nova side we had a failure around unit tests which
> >>> was quite synthetic that we fixed. I don' know what the keystone issue
> >>> turned out to be.
> >>>
> >>
> >> I believe the keystone issue was a test specific issue, not a runtime
> >> issue. We disabled the test.
> >> --Morgan
> > 
> > OK. Can someone from the neutron team verify that 0.18.2 works? If so,
> > we can just exclude 0.18.3 and reset the constraint.
> 
> I can confirm that neutron works with 0.18.2 as far as we know.
> 

Great. If you (or someone else) wants to submit a requirements update, I
can approve it. Ping me in #openstack-release.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-17 Thread Henry Gessau
Doug Hellmann  wrote:
> Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800:
>> On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague  wrote:
>>
>>> On 02/17/2016 08:42 AM, Doug Hellmann wrote:
 Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100:
> Le 17/02/2016 13:43, Henry Gessau a écrit :
>> And it looks like eventlet 0.18.3 breaks neutron:
>> https://bugs.launchpad.net/neutron/+bug/1546506
>
> 2 releases, 2 regressions in OpenStack. Should we cap eventlet version?
> The requirement bot can produce patches to update eventlet, patches
> which would run integration tests using Nova, Keystone, Neutron on the
> new eventlet version.
>
> eventlet 0.18.2 broke OpenStack Keystone and OpenStack Nova
> https://github.com/eventlet/eventlet/issues/296
> https://github.com/eventlet/eventlet/issues/299
> https://review.openstack.org/#/c/278147/
> https://bugs.launchpad.net/nova/+bug/1544801
>
> eventlet 0.18.3 broke OpenStack Neutron
> https://github.com/eventlet/eventlet/issues/301
> https://bugs.launchpad.net/neutron/+bug/1546506
>
> FYI eventlet 0.18.0 broke WSGI servers:
> https://github.com/eventlet/eventlet/issues/295
>
> It was followed quickly by eventlet 0.18.2 to fix this issue.
>
> Sadly, it looks like bugfix releases of eventlet don't include a single
> bugfix, but include also other changes. For example, 0.18.3 fixed the
> bug #296 but introduced "wsgi: TCP_NODELAY enabled by default"
>>> optimization.
>
> IMHO the problem is not the release manager of eventlet, but more the
> lack of tests on eventlet, especially on OpenStack services.
>
> Current "Continious Delivery"-like with gates do detect bugs, yeah, but
> also block a lot of developers when the gates are broken. It doesn't
> seem trivial to investigate and fix eventlet issues.
>
> Victor
>

 Whether we cap or not, we should exclude the known broken versions.
 It looks like getting back to a good version will also require
 lowering the minimum version we support, since we have >=0.18.2
 now.

 What was the last version of eventlet known to work?
>>>
>>> 0.18.2 works. On the Nova side we had a failure around unit tests which
>>> was quite synthetic that we fixed. I don' know what the keystone issue
>>> turned out to be.
>>>
>>
>> I believe the keystone issue was a test specific issue, not a runtime
>> issue. We disabled the test.
>> --Morgan
> 
> OK. Can someone from the neutron team verify that 0.18.2 works? If so,
> we can just exclude 0.18.3 and reset the constraint.

I can confirm that neutron works with 0.18.2 as far as we know.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-17 Thread Doug Hellmann
Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800:
> On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague  wrote:
> 
> > On 02/17/2016 08:42 AM, Doug Hellmann wrote:
> > > Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100:
> > >> Le 17/02/2016 13:43, Henry Gessau a écrit :
> > >>> And it looks like eventlet 0.18.3 breaks neutron:
> > >>> https://bugs.launchpad.net/neutron/+bug/1546506
> > >>
> > >> 2 releases, 2 regressions in OpenStack. Should we cap eventlet version?
> > >> The requirement bot can produce patches to update eventlet, patches
> > >> which would run integration tests using Nova, Keystone, Neutron on the
> > >> new eventlet version.
> > >>
> > >> eventlet 0.18.2 broke OpenStack Keystone and OpenStack Nova
> > >> https://github.com/eventlet/eventlet/issues/296
> > >> https://github.com/eventlet/eventlet/issues/299
> > >> https://review.openstack.org/#/c/278147/
> > >> https://bugs.launchpad.net/nova/+bug/1544801
> > >>
> > >> eventlet 0.18.3 broke OpenStack Neutron
> > >> https://github.com/eventlet/eventlet/issues/301
> > >> https://bugs.launchpad.net/neutron/+bug/1546506
> > >>
> > >> FYI eventlet 0.18.0 broke WSGI servers:
> > >> https://github.com/eventlet/eventlet/issues/295
> > >>
> > >> It was followed quickly by eventlet 0.18.2 to fix this issue.
> > >>
> > >> Sadly, it looks like bugfix releases of eventlet don't include a single
> > >> bugfix, but include also other changes. For example, 0.18.3 fixed the
> > >> bug #296 but introduced "wsgi: TCP_NODELAY enabled by default"
> > optimization.
> > >>
> > >> IMHO the problem is not the release manager of eventlet, but more the
> > >> lack of tests on eventlet, especially on OpenStack services.
> > >>
> > >> Current "Continious Delivery"-like with gates do detect bugs, yeah, but
> > >> also block a lot of developers when the gates are broken. It doesn't
> > >> seem trivial to investigate and fix eventlet issues.
> > >>
> > >> Victor
> > >>
> > >
> > > Whether we cap or not, we should exclude the known broken versions.
> > > It looks like getting back to a good version will also require
> > > lowering the minimum version we support, since we have >=0.18.2
> > > now.
> > >
> > > What was the last version of eventlet known to work?
> >
> > 0.18.2 works. On the Nova side we had a failure around unit tests which
> > was quite synthetic that we fixed. I don' know what the keystone issue
> > turned out to be.
> >
> 
> I believe the keystone issue was a test specific issue, not a runtime
> issue. We disabled the test.
> --Morgan

OK. Can someone from the neutron team verify that 0.18.2 works? If so,
we can just exclude 0.18.3 and reset the constraint.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-17 Thread Morgan Fainberg
On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague  wrote:

> On 02/17/2016 08:42 AM, Doug Hellmann wrote:
> > Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100:
> >> Le 17/02/2016 13:43, Henry Gessau a écrit :
> >>> And it looks like eventlet 0.18.3 breaks neutron:
> >>> https://bugs.launchpad.net/neutron/+bug/1546506
> >>
> >> 2 releases, 2 regressions in OpenStack. Should we cap eventlet version?
> >> The requirement bot can produce patches to update eventlet, patches
> >> which would run integration tests using Nova, Keystone, Neutron on the
> >> new eventlet version.
> >>
> >> eventlet 0.18.2 broke OpenStack Keystone and OpenStack Nova
> >> https://github.com/eventlet/eventlet/issues/296
> >> https://github.com/eventlet/eventlet/issues/299
> >> https://review.openstack.org/#/c/278147/
> >> https://bugs.launchpad.net/nova/+bug/1544801
> >>
> >> eventlet 0.18.3 broke OpenStack Neutron
> >> https://github.com/eventlet/eventlet/issues/301
> >> https://bugs.launchpad.net/neutron/+bug/1546506
> >>
> >> FYI eventlet 0.18.0 broke WSGI servers:
> >> https://github.com/eventlet/eventlet/issues/295
> >>
> >> It was followed quickly by eventlet 0.18.2 to fix this issue.
> >>
> >> Sadly, it looks like bugfix releases of eventlet don't include a single
> >> bugfix, but include also other changes. For example, 0.18.3 fixed the
> >> bug #296 but introduced "wsgi: TCP_NODELAY enabled by default"
> optimization.
> >>
> >> IMHO the problem is not the release manager of eventlet, but more the
> >> lack of tests on eventlet, especially on OpenStack services.
> >>
> >> Current "Continious Delivery"-like with gates do detect bugs, yeah, but
> >> also block a lot of developers when the gates are broken. It doesn't
> >> seem trivial to investigate and fix eventlet issues.
> >>
> >> Victor
> >>
> >
> > Whether we cap or not, we should exclude the known broken versions.
> > It looks like getting back to a good version will also require
> > lowering the minimum version we support, since we have >=0.18.2
> > now.
> >
> > What was the last version of eventlet known to work?
>
> 0.18.2 works. On the Nova side we had a failure around unit tests which
> was quite synthetic that we fixed. I don' know what the keystone issue
> turned out to be.
>

I believe the keystone issue was a test specific issue, not a runtime
issue. We disabled the test.
--Morgan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-17 Thread Sean Dague
On 02/17/2016 08:42 AM, Doug Hellmann wrote:
> Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100:
>> Le 17/02/2016 13:43, Henry Gessau a écrit :
>>> And it looks like eventlet 0.18.3 breaks neutron:
>>> https://bugs.launchpad.net/neutron/+bug/1546506
>>
>> 2 releases, 2 regressions in OpenStack. Should we cap eventlet version? 
>> The requirement bot can produce patches to update eventlet, patches 
>> which would run integration tests using Nova, Keystone, Neutron on the 
>> new eventlet version.
>>
>> eventlet 0.18.2 broke OpenStack Keystone and OpenStack Nova
>> https://github.com/eventlet/eventlet/issues/296
>> https://github.com/eventlet/eventlet/issues/299
>> https://review.openstack.org/#/c/278147/
>> https://bugs.launchpad.net/nova/+bug/1544801
>>
>> eventlet 0.18.3 broke OpenStack Neutron
>> https://github.com/eventlet/eventlet/issues/301
>> https://bugs.launchpad.net/neutron/+bug/1546506
>>
>> FYI eventlet 0.18.0 broke WSGI servers:
>> https://github.com/eventlet/eventlet/issues/295
>>
>> It was followed quickly by eventlet 0.18.2 to fix this issue.
>>
>> Sadly, it looks like bugfix releases of eventlet don't include a single 
>> bugfix, but include also other changes. For example, 0.18.3 fixed the 
>> bug #296 but introduced "wsgi: TCP_NODELAY enabled by default" optimization.
>>
>> IMHO the problem is not the release manager of eventlet, but more the 
>> lack of tests on eventlet, especially on OpenStack services.
>>
>> Current "Continious Delivery"-like with gates do detect bugs, yeah, but 
>> also block a lot of developers when the gates are broken. It doesn't 
>> seem trivial to investigate and fix eventlet issues.
>>
>> Victor
>>
> 
> Whether we cap or not, we should exclude the known broken versions.
> It looks like getting back to a good version will also require
> lowering the minimum version we support, since we have >=0.18.2
> now.
> 
> What was the last version of eventlet known to work?

0.18.2 works. On the Nova side we had a failure around unit tests which
was quite synthetic that we fixed. I don' know what the keystone issue
turned out to be.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-17 Thread Davanum Srinivas
I'd support this,

Last known version is https://pypi.python.org/pypi/eventlet/0.17.4

-- Dims

On Wed, Feb 17, 2016 at 8:42 AM, Doug Hellmann  wrote:
> Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100:
>> Le 17/02/2016 13:43, Henry Gessau a écrit :
>> > And it looks like eventlet 0.18.3 breaks neutron:
>> > https://bugs.launchpad.net/neutron/+bug/1546506
>>
>> 2 releases, 2 regressions in OpenStack. Should we cap eventlet version?
>> The requirement bot can produce patches to update eventlet, patches
>> which would run integration tests using Nova, Keystone, Neutron on the
>> new eventlet version.
>>
>> eventlet 0.18.2 broke OpenStack Keystone and OpenStack Nova
>> https://github.com/eventlet/eventlet/issues/296
>> https://github.com/eventlet/eventlet/issues/299
>> https://review.openstack.org/#/c/278147/
>> https://bugs.launchpad.net/nova/+bug/1544801
>>
>> eventlet 0.18.3 broke OpenStack Neutron
>> https://github.com/eventlet/eventlet/issues/301
>> https://bugs.launchpad.net/neutron/+bug/1546506
>>
>> FYI eventlet 0.18.0 broke WSGI servers:
>> https://github.com/eventlet/eventlet/issues/295
>>
>> It was followed quickly by eventlet 0.18.2 to fix this issue.
>>
>> Sadly, it looks like bugfix releases of eventlet don't include a single
>> bugfix, but include also other changes. For example, 0.18.3 fixed the
>> bug #296 but introduced "wsgi: TCP_NODELAY enabled by default" optimization.
>>
>> IMHO the problem is not the release manager of eventlet, but more the
>> lack of tests on eventlet, especially on OpenStack services.
>>
>> Current "Continious Delivery"-like with gates do detect bugs, yeah, but
>> also block a lot of developers when the gates are broken. It doesn't
>> seem trivial to investigate and fix eventlet issues.
>>
>> Victor
>>
>
> Whether we cap or not, we should exclude the known broken versions.
> It looks like getting back to a good version will also require
> lowering the minimum version we support, since we have >=0.18.2
> now.
>
> What was the last version of eventlet known to work?
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-17 Thread Doug Hellmann
Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100:
> Le 17/02/2016 13:43, Henry Gessau a écrit :
> > And it looks like eventlet 0.18.3 breaks neutron:
> > https://bugs.launchpad.net/neutron/+bug/1546506
> 
> 2 releases, 2 regressions in OpenStack. Should we cap eventlet version? 
> The requirement bot can produce patches to update eventlet, patches 
> which would run integration tests using Nova, Keystone, Neutron on the 
> new eventlet version.
> 
> eventlet 0.18.2 broke OpenStack Keystone and OpenStack Nova
> https://github.com/eventlet/eventlet/issues/296
> https://github.com/eventlet/eventlet/issues/299
> https://review.openstack.org/#/c/278147/
> https://bugs.launchpad.net/nova/+bug/1544801
> 
> eventlet 0.18.3 broke OpenStack Neutron
> https://github.com/eventlet/eventlet/issues/301
> https://bugs.launchpad.net/neutron/+bug/1546506
> 
> FYI eventlet 0.18.0 broke WSGI servers:
> https://github.com/eventlet/eventlet/issues/295
> 
> It was followed quickly by eventlet 0.18.2 to fix this issue.
> 
> Sadly, it looks like bugfix releases of eventlet don't include a single 
> bugfix, but include also other changes. For example, 0.18.3 fixed the 
> bug #296 but introduced "wsgi: TCP_NODELAY enabled by default" optimization.
> 
> IMHO the problem is not the release manager of eventlet, but more the 
> lack of tests on eventlet, especially on OpenStack services.
> 
> Current "Continious Delivery"-like with gates do detect bugs, yeah, but 
> also block a lot of developers when the gates are broken. It doesn't 
> seem trivial to investigate and fix eventlet issues.
> 
> Victor
> 

Whether we cap or not, we should exclude the known broken versions.
It looks like getting back to a good version will also require
lowering the minimum version we support, since we have >=0.18.2
now.

What was the last version of eventlet known to work?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-17 Thread Victor Stinner

Le 17/02/2016 13:43, Henry Gessau a écrit :

And it looks like eventlet 0.18.3 breaks neutron:
https://bugs.launchpad.net/neutron/+bug/1546506


2 releases, 2 regressions in OpenStack. Should we cap eventlet version? 
The requirement bot can produce patches to update eventlet, patches 
which would run integration tests using Nova, Keystone, Neutron on the 
new eventlet version.


eventlet 0.18.2 broke OpenStack Keystone and OpenStack Nova
https://github.com/eventlet/eventlet/issues/296
https://github.com/eventlet/eventlet/issues/299
https://review.openstack.org/#/c/278147/
https://bugs.launchpad.net/nova/+bug/1544801

eventlet 0.18.3 broke OpenStack Neutron
https://github.com/eventlet/eventlet/issues/301
https://bugs.launchpad.net/neutron/+bug/1546506

FYI eventlet 0.18.0 broke WSGI servers:
https://github.com/eventlet/eventlet/issues/295

It was followed quickly by eventlet 0.18.2 to fix this issue.

Sadly, it looks like bugfix releases of eventlet don't include a single 
bugfix, but include also other changes. For example, 0.18.3 fixed the 
bug #296 but introduced "wsgi: TCP_NODELAY enabled by default" optimization.


IMHO the problem is not the release manager of eventlet, but more the 
lack of tests on eventlet, especially on OpenStack services.


Current "Continious Delivery"-like with gates do detect bugs, yeah, but 
also block a lot of developers when the gates are broken. It doesn't 
seem trivial to investigate and fix eventlet issues.


Victor

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-17 Thread Henry Gessau
And it looks like eventlet 0.18.3 breaks neutron:
https://bugs.launchpad.net/neutron/+bug/1546506

Victor Stinner  wrote:
> Hi,
> 
> I asked eventlet dev to *not* remove a release from PyPI before they did 
> it, but they ignored me and removed 0.18.0 and 0.18.1 releases from PyPI :-(
> 
> 0.18.0 fixed a bug in Python 3:
> https://github.com/eventlet/eventlet/issues/274
> 
> But 0.18.0 introduced a regression on Python 3 in WSGI:
> https://github.com/eventlet/eventlet/issues/295
> 
> 0.18.2 was supposed to fix the WSGI bug, but introduced a different bug 
> in Keystone:
> https://github.com/eventlet/eventlet/issues/296
> 
> Yeah, it's funny to work on eventlet :-) A new bug everyday :-D
> 
> At least, the eventlet test suite is completed at each bugfix.
> 
> Victor
> 
> Le 09/02/2016 17:44, Markus Zoeller a écrit :
>> For the sake of completeness: The eventlet package version 0.18.1
>> seems to be disappeared from the PyPi servers, which is a bad thing,
>> as we use that version in the "upper-constraints.txt" of the
>> requirements project. There is patch [1] in the queue which solves that.
>> Until this is merged, there is a change that our CI (and your third-party
>> CI) will break after the locally cached version in the CI vanishes.
>>
>> References:
>> [1] https://review.openstack.org/#/c/277912/
>>
>> Regards, Markus Zoeller (markus_z)
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-09 Thread Monty Taylor

On 02/09/2016 12:24 PM, McLellan, Steven wrote:

 From the list of versions that are there
(https://pypi.python.org/simple/eventlet/), it appears that for a given
major version only the most recent release is kept, so this will likely
reoccur when/if 0.18.3 is released.


Anybody know anybody in eventlet land who we could talk to about their 
release process? PyPI will automatically hide old releases for them, so 
there is really no need to delete previous point releases (and as we all 
know this causes OpenStack considerable pain)



On 2/9/16, 10:44 AM, "Markus Zoeller"  wrote:


For the sake of completeness: The eventlet package version 0.18.1
seems to be disappeared from the PyPi servers, which is a bad thing,
as we use that version in the "upper-constraints.txt" of the
requirements project. There is patch [1] in the queue which solves that.
Until this is merged, there is a change that our CI (and your third-party
CI) will break after the locally cached version in the CI vanishes.

References:
[1] https://review.openstack.org/#/c/277912/

Regards, Markus Zoeller (markus_z)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-09 Thread Markus Zoeller
For the sake of completeness: The eventlet package version 0.18.1
seems to be disappeared from the PyPi servers, which is a bad thing,
as we use that version in the "upper-constraints.txt" of the
requirements project. There is patch [1] in the queue which solves that.
Until this is merged, there is a change that our CI (and your third-party
CI) will break after the locally cached version in the CI vanishes.

References:
[1] https://review.openstack.org/#/c/277912/

Regards, Markus Zoeller (markus_z)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-09 Thread Davanum Srinivas
Monty,

I asked for details and got a response here:
https://github.com/eventlet/eventlet/commit/5bf0a6f32b3e4459b38ad1895c9eb4b0b483dae1#commitcomment-15987613

-- Dims

On Tue, Feb 9, 2016 at 2:05 PM, Monty Taylor  wrote:
> On 02/09/2016 12:24 PM, McLellan, Steven wrote:
>>
>>  From the list of versions that are there
>> (https://pypi.python.org/simple/eventlet/), it appears that for a given
>> major version only the most recent release is kept, so this will likely
>> reoccur when/if 0.18.3 is released.
>
>
> Anybody know anybody in eventlet land who we could talk to about their
> release process? PyPI will automatically hide old releases for them, so
> there is really no need to delete previous point releases (and as we all
> know this causes OpenStack considerable pain)
>
>
>> On 2/9/16, 10:44 AM, "Markus Zoeller"  wrote:
>>
>>> For the sake of completeness: The eventlet package version 0.18.1
>>> seems to be disappeared from the PyPi servers, which is a bad thing,
>>> as we use that version in the "upper-constraints.txt" of the
>>> requirements project. There is patch [1] in the queue which solves that.
>>> Until this is merged, there is a change that our CI (and your third-party
>>> CI) will break after the locally cached version in the CI vanishes.
>>>
>>> References:
>>> [1] https://review.openstack.org/#/c/277912/
>>>
>>> Regards, Markus Zoeller (markus_z)
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-09 Thread McLellan, Steven
>From the list of versions that are there
(https://pypi.python.org/simple/eventlet/), it appears that for a given
major version only the most recent release is kept, so this will likely
reoccur when/if 0.18.3 is released.

Steve

On 2/9/16, 10:44 AM, "Markus Zoeller"  wrote:

>For the sake of completeness: The eventlet package version 0.18.1
>seems to be disappeared from the PyPi servers, which is a bad thing,
>as we use that version in the "upper-constraints.txt" of the
>requirements project. There is patch [1] in the queue which solves that.
>Until this is merged, there is a change that our CI (and your third-party
>CI) will break after the locally cached version in the CI vanishes.
>
>References:
>[1] https://review.openstack.org/#/c/277912/
>
>Regards, Markus Zoeller (markus_z)
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev