Re: [openstack-dev] [all][requirements] uncapping eventlet

2018-05-07 Thread John Dickinson
I've discovered that eventlet 0.23.0 (released April 6) does break 
things for Swift. I'm not sure about other projects yet.


https://bugs.launchpad.net/swift/+bug/1769749

--John




On 7 May 2018, at 13:50, Doug Hellmann wrote:


Excerpts from Michel Peterson's message of 2018-05-07 17:54:02 +0300:
On Fri, Apr 20, 2018 at 11:06 PM, Doug Hellmann 


wrote:



We have made great progress on this but we do still have quite a
few of these patches that have not been approved.  Many are failing
test jobs and will need a little attention ( the failing 
requirements

jobs are real problems and rechecking will not fix them).  If you
have time to help, please jump in and take over a patch and get it
working.

https://review.openstack.org/#/q/status:open+topic:uncap-eventlet



I did a script to fix those and I've submitted patches.


Thanks!

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


__
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][requirements] uncapping eventlet

2018-05-07 Thread Doug Hellmann
Excerpts from Michel Peterson's message of 2018-05-07 17:54:02 +0300:
> On Fri, Apr 20, 2018 at 11:06 PM, Doug Hellmann 
> wrote:
> 
> >
> > We have made great progress on this but we do still have quite a
> > few of these patches that have not been approved.  Many are failing
> > test jobs and will need a little attention ( the failing requirements
> > jobs are real problems and rechecking will not fix them).  If you
> > have time to help, please jump in and take over a patch and get it
> > working.
> >
> > https://review.openstack.org/#/q/status:open+topic:uncap-eventlet
> >
> >
> I did a script to fix those and I've submitted patches.

Thanks!

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][requirements] uncapping eventlet

2018-05-07 Thread Michel Peterson
On Fri, Apr 20, 2018 at 11:06 PM, Doug Hellmann 
wrote:

>
> We have made great progress on this but we do still have quite a
> few of these patches that have not been approved.  Many are failing
> test jobs and will need a little attention ( the failing requirements
> jobs are real problems and rechecking will not fix them).  If you
> have time to help, please jump in and take over a patch and get it
> working.
>
> https://review.openstack.org/#/q/status:open+topic:uncap-eventlet
>
>
I did a script to fix those and I've submitted patches.
__
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][requirements] uncapping eventlet

2018-04-20 Thread Doug Hellmann
Excerpts from Doug Hellmann's message of 2018-04-11 12:20:46 -0400:
> Excerpts from Matthew Thode's message of 2018-04-05 10:47:37 -0500:
> > eventlet-0.22.1 has been out for a while now, we should try and use it.
> > Going to be fun times.
> > 
> > I have a review projects can depend upon if they wish to test.
> > https://review.openstack.org/533021
> 
> I have proposed a bunch of patches to projects to remove the cap
> for eventlet [1]. If they don't pass tests, please take them over
> and fix them up as needed (I anticipate some trouble with the new
> check-requirements rules, for example).
> 
> Doug
> 
> [1] 
> https://review.openstack.org/#/q/topic:uncap-eventlet+(status:open+OR+status:merged)

We have made great progress on this but we do still have quite a
few of these patches that have not been approved.  Many are failing
test jobs and will need a little attention ( the failing requirements
jobs are real problems and rechecking will not fix them).  If you
have time to help, please jump in and take over a patch and get it
working.

https://review.openstack.org/#/q/status:open+topic:uncap-eventlet

Thanks,
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][requirements] uncapping eventlet

2018-04-11 Thread Doug Hellmann
Excerpts from Doug Hellmann's message of 2018-04-11 12:20:46 -0400:
> Excerpts from Matthew Thode's message of 2018-04-05 10:47:37 -0500:
> > eventlet-0.22.1 has been out for a while now, we should try and use it.
> > Going to be fun times.
> > 
> > I have a review projects can depend upon if they wish to test.
> > https://review.openstack.org/533021
> 
> I have proposed a bunch of patches to projects to remove the cap
> for eventlet [1]. If they don't pass tests, please take them over
> and fix them up as needed (I anticipate some trouble with the new
> check-requirements rules, for example).
> 
> Doug
> 
> [1] 
> https://review.openstack.org/#/q/topic:uncap-eventlet+(status:open+OR+status:merged)

And please go ahead and abandon any that are duplicates for patches that
are already being worked on elsewhere. It was easier to just update
everything than to script something to figure out when updates were
needed.

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][requirements] uncapping eventlet

2018-04-11 Thread Doug Hellmann
Excerpts from Matthew Thode's message of 2018-04-05 10:47:37 -0500:
> eventlet-0.22.1 has been out for a while now, we should try and use it.
> Going to be fun times.
> 
> I have a review projects can depend upon if they wish to test.
> https://review.openstack.org/533021

I have proposed a bunch of patches to projects to remove the cap
for eventlet [1]. If they don't pass tests, please take them over
and fix them up as needed (I anticipate some trouble with the new
check-requirements rules, for example).

Doug

[1] 
https://review.openstack.org/#/q/topic:uncap-eventlet+(status:open+OR+status:merged)

__
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][requirements] uncapping eventlet

2018-04-11 Thread Doug Hellmann
Excerpts from Chen CH Ji's message of 2018-04-11 21:09:29 +0800:
> sorry, I didn't see any solution for following error found in [1]
> I just rechecked the patch and is this kind of issue already fixed?
> 
> ubuntu-xenial | Requirement for package eventlet : Requirement
> (package=u'eventlet', location='',
> specifiers='!=0.18.3,!=0.20.1,<0.21.0,>=0.18.2', markers=u'', comment=u'#
> MIT', extras=frozenset([])) does not match openstack/requirements value :
> set([Requirement(package='eventlet', location='',
> specifiers='!=0.18.3,!=0.20.1,>=0.18.2', markers='', comment='# MIT',
> extras=frozenset([]))])

The error message is correct. The requirements specification does not
match and needs to be fixed by removing the cap from eventlet.

Doug

> 
> [1]
> logs.openstack.org/87/523387/32/check/requirements-check/408e28c/job-output.txt.gz
> 
> Best Regards!
> 
> Kevin (Chen) Ji 纪 晨
> 
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
> Phone: +86-10-82451493
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
> Beijing 100193, PRC
> 
> 
> 
> From:Doug Hellmann <d...@doughellmann.com>
> To:openstack-dev <openstack-dev@lists.openstack.org>
> Date:04/11/2018 08:56 PM
> Subject:Re: [openstack-dev] [all][requirements] uncapping eventlet
> 
> Excerpts from IWAMOTO Toshihiro's message of 2018-04-11 18:19:02 +0900:
> > On Mon, 09 Apr 2018 22:58:28 +0900,
> > Doug Hellmann wrote:
> > >
> > > Excerpts from Tony Breeds's message of 2018-04-09 13:39:30 +1000:
> > > > On Fri, Apr 06, 2018 at 09:41:07AM -0700, Clark Boylan wrote:
> > > >
> > > > > My understanding of our use of upper constraints was that this
> should
> > > > > (almost) always be the case for (almost) all dependencies.  We
> should
> > > > > rely on constraints instead of requirements caps. Capping libs like
> > > > > pbr or eventlet and any other that is in use globally is incredibly
> > > > > difficult to work with when you want to uncap it because you have
> to
> > > > > coordinate globally. Instead if using constraints you just bump the
> > > > > constraint and are done.
> > > >
> > > > Part of the reason that we have the caps it to prevent the tools that
> > > > auto-generate the constraints syncs from considering these versions
> and
> > > > then depending on the requirements team to strip that from the bot
> > > > change before committing (assuming it passes CI).
> > > >
> > > > Once the work Doug's doing is complete we could consider tweaking the
> > > > tools to use a different mechanism, but that's only part of the
> reason
> > > > for the caps in g-r.
> > > >
> > > > Yours Tony.
> > >
> > > Now that projects don't have to match the global requirements list
> > > entries exactly we should be able to remove caps from within the
> > > projects and keep caps in the global list for cases like this where we
> > > know we frequently encounter breaking changes in new releases. The
> > > changes to support that were part of
> > >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_555402_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=y9YWvP5nDDQCyw3QGNWGvQS-CVeHBeXA9rfHaLf3JpQ=P99Z7BlpiP8Sg9_5Ku4JMW_tJWXARpd2ldSvFFlFBpU=
> 
> >
> > As eventlet has been uncapped in g-r, requirements-check is
> > complaining on unrelated project-local requirement changes.
> > I'm not quite sure but doesn't seem to be a intended behavior.
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__logs.openstack.org_57_451257_16_check_requirements-2Dcheck_c32ee69_job-2Doutput.txt.gz=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=y9YWvP5nDDQCyw3QGNWGvQS-CVeHBeXA9rfHaLf3JpQ=6uHgERcFttsqFakjBTrjvKZhk5n-tZO-e0QMd7zj0nc=
> 
> >
> 
> This error is related to the change in
> https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_560050_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=y9YWvP5nDDQCyw3QGNWGvQS-CVeHBeXA9rfHaLf3JpQ=1hIA6J9OfM1mhcTDq89NkGmoAQi_fDfhel7q5dgcwIA=
>  which applies the matching
> rules to all requirements settings any time any requirements-related
> file is touched. The change was made because we are less in-sync than we
> thought and because we're allowing "bad" settings to stay in place.
> 
> To correct the problem in the log you linked to, remove the cap from
> eventlet in neutron.
> 
> 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][requirements] uncapping eventlet

2018-04-11 Thread Chen CH Ji
sorry, I didn't see any solution for following error found in [1]
I just rechecked the patch and is this kind of issue already fixed?

ubuntu-xenial | Requirement for package eventlet : Requirement
(package=u'eventlet', location='',
specifiers='!=0.18.3,!=0.20.1,<0.21.0,>=0.18.2', markers=u'', comment=u'#
MIT', extras=frozenset([])) does not match openstack/requirements value :
set([Requirement(package='eventlet', location='',
specifiers='!=0.18.3,!=0.20.1,>=0.18.2', markers='', comment='# MIT',
extras=frozenset([]))])

[1]
logs.openstack.org/87/523387/32/check/requirements-check/408e28c/job-output.txt.gz

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Doug Hellmann <d...@doughellmann.com>
To: openstack-dev <openstack-dev@lists.openstack.org>
Date:   04/11/2018 08:56 PM
Subject:        Re: [openstack-dev] [all][requirements] uncapping eventlet



Excerpts from IWAMOTO Toshihiro's message of 2018-04-11 18:19:02 +0900:
> On Mon, 09 Apr 2018 22:58:28 +0900,
> Doug Hellmann wrote:
> >
> > Excerpts from Tony Breeds's message of 2018-04-09 13:39:30 +1000:
> > > On Fri, Apr 06, 2018 at 09:41:07AM -0700, Clark Boylan wrote:
> > >
> > > > My understanding of our use of upper constraints was that this
should
> > > > (almost) always be the case for (almost) all dependencies.  We
should
> > > > rely on constraints instead of requirements caps. Capping libs like
> > > > pbr or eventlet and any other that is in use globally is incredibly
> > > > difficult to work with when you want to uncap it because you have
to
> > > > coordinate globally. Instead if using constraints you just bump the
> > > > constraint and are done.
> > >
> > > Part of the reason that we have the caps it to prevent the tools that
> > > auto-generate the constraints syncs from considering these versions
and
> > > then depending on the requirements team to strip that from the bot
> > > change before committing (assuming it passes CI).
> > >
> > > Once the work Doug's doing is complete we could consider tweaking the
> > > tools to use a different mechanism, but that's only part of the
reason
> > > for the caps in g-r.
> > >
> > > Yours Tony.
> >
> > Now that projects don't have to match the global requirements list
> > entries exactly we should be able to remove caps from within the
> > projects and keep caps in the global list for cases like this where we
> > know we frequently encounter breaking changes in new releases. The
> > changes to support that were part of
> >
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_555402_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=y9YWvP5nDDQCyw3QGNWGvQS-CVeHBeXA9rfHaLf3JpQ=P99Z7BlpiP8Sg9_5Ku4JMW_tJWXARpd2ldSvFFlFBpU=

>
> As eventlet has been uncapped in g-r, requirements-check is
> complaining on unrelated project-local requirement changes.
> I'm not quite sure but doesn't seem to be a intended behavior.
>
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__logs.openstack.org_57_451257_16_check_requirements-2Dcheck_c32ee69_job-2Doutput.txt.gz=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=y9YWvP5nDDQCyw3QGNWGvQS-CVeHBeXA9rfHaLf3JpQ=6uHgERcFttsqFakjBTrjvKZhk5n-tZO-e0QMd7zj0nc=

>

This error is related to the change in
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_560050_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=y9YWvP5nDDQCyw3QGNWGvQS-CVeHBeXA9rfHaLf3JpQ=1hIA6J9OfM1mhcTDq89NkGmoAQi_fDfhel7q5dgcwIA=
 which applies the matching
rules to all requirements settings any time any requirements-related
file is touched. The change was made because we are less in-sync than we
thought and because we're allowing "bad" settings to stay in place.

To correct the problem in the log you linked to, remove the cap from
eventlet in neutron.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=y9YWvP5nDDQCyw3QGNWGvQS-CVeHBeXA9rfHaLf3JpQ=nEWykx9Cfm6deVwO9Sdge-_Q31mCbdfAmvp_KoPaenc=




__
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][requirements] uncapping eventlet

2018-04-11 Thread Doug Hellmann
Excerpts from IWAMOTO Toshihiro's message of 2018-04-11 18:19:02 +0900:
> On Mon, 09 Apr 2018 22:58:28 +0900,
> Doug Hellmann wrote:
> > 
> > Excerpts from Tony Breeds's message of 2018-04-09 13:39:30 +1000:
> > > On Fri, Apr 06, 2018 at 09:41:07AM -0700, Clark Boylan wrote:
> > > 
> > > > My understanding of our use of upper constraints was that this should
> > > > (almost) always be the case for (almost) all dependencies.  We should
> > > > rely on constraints instead of requirements caps. Capping libs like
> > > > pbr or eventlet and any other that is in use globally is incredibly
> > > > difficult to work with when you want to uncap it because you have to
> > > > coordinate globally. Instead if using constraints you just bump the
> > > > constraint and are done.
> > > 
> > > Part of the reason that we have the caps it to prevent the tools that
> > > auto-generate the constraints syncs from considering these versions and
> > > then depending on the requirements team to strip that from the bot
> > > change before committing (assuming it passes CI).
> > > 
> > > Once the work Doug's doing is complete we could consider tweaking the
> > > tools to use a different mechanism, but that's only part of the reason
> > > for the caps in g-r.
> > > 
> > > Yours Tony.
> > 
> > Now that projects don't have to match the global requirements list
> > entries exactly we should be able to remove caps from within the
> > projects and keep caps in the global list for cases like this where we
> > know we frequently encounter breaking changes in new releases. The
> > changes to support that were part of
> > https://review.openstack.org/#/c/555402/
> 
> As eventlet has been uncapped in g-r, requirements-check is
> complaining on unrelated project-local requirement changes.
> I'm not quite sure but doesn't seem to be a intended behavior.
> 
> http://logs.openstack.org/57/451257/16/check/requirements-check/c32ee69/job-output.txt.gz
> 

This error is related to the change in
https://review.openstack.org/#/c/560050/ which applies the matching
rules to all requirements settings any time any requirements-related
file is touched. The change was made because we are less in-sync than we
thought and because we're allowing "bad" settings to stay in place.

To correct the problem in the log you linked to, remove the cap from
eventlet in neutron.

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][requirements] uncapping eventlet

2018-04-11 Thread IWAMOTO Toshihiro
On Mon, 09 Apr 2018 22:58:28 +0900,
Doug Hellmann wrote:
> 
> Excerpts from Tony Breeds's message of 2018-04-09 13:39:30 +1000:
> > On Fri, Apr 06, 2018 at 09:41:07AM -0700, Clark Boylan wrote:
> > 
> > > My understanding of our use of upper constraints was that this should
> > > (almost) always be the case for (almost) all dependencies.  We should
> > > rely on constraints instead of requirements caps. Capping libs like
> > > pbr or eventlet and any other that is in use globally is incredibly
> > > difficult to work with when you want to uncap it because you have to
> > > coordinate globally. Instead if using constraints you just bump the
> > > constraint and are done.
> > 
> > Part of the reason that we have the caps it to prevent the tools that
> > auto-generate the constraints syncs from considering these versions and
> > then depending on the requirements team to strip that from the bot
> > change before committing (assuming it passes CI).
> > 
> > Once the work Doug's doing is complete we could consider tweaking the
> > tools to use a different mechanism, but that's only part of the reason
> > for the caps in g-r.
> > 
> > Yours Tony.
> 
> Now that projects don't have to match the global requirements list
> entries exactly we should be able to remove caps from within the
> projects and keep caps in the global list for cases like this where we
> know we frequently encounter breaking changes in new releases. The
> changes to support that were part of
> https://review.openstack.org/#/c/555402/

As eventlet has been uncapped in g-r, requirements-check is
complaining on unrelated project-local requirement changes.
I'm not quite sure but doesn't seem to be a intended behavior.

http://logs.openstack.org/57/451257/16/check/requirements-check/c32ee69/job-output.txt.gz

--
IWAMOTO Toshihiro

__
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][requirements] uncapping eventlet

2018-04-10 Thread Ben Nemec



On 04/09/2018 04:32 PM, Ben Nemec wrote:



On 04/09/2018 01:12 PM, Ben Nemec wrote:



On 04/06/2018 04:02 AM, Jens Harbott wrote:

2018-04-05 19:26 GMT+00:00 Matthew Thode :

On 18-04-05 20:11:04, Graham Hayes wrote:

On 05/04/18 16:47, Matthew Thode wrote:
eventlet-0.22.1 has been out for a while now, we should try and 
use it.

Going to be fun times.

I have a review projects can depend upon if they wish to test.
https://review.openstack.org/533021


It looks like we may have an issue with oslo.service -
https://review.openstack.org/#/c/559144/ is failing gates.

Also - what is the dance for this to get merged? It doesn't look 
like we
can merge this while oslo.service has the old requirement 
restrictions.




The dance is as follows.

0. provide review for projects to test new eventlet version
    projects using eventlet should make backwards compat code 
changes at

    this time.


But this step is currently failing. Keystone doesn't even start when
eventlet-0.22.1 is installed, because loading oslo.service fails with
its pkg definition still requiring the capped eventlet:

http://logs.openstack.org/21/533021/4/check/legacy-requirements-integration-dsvm/7f7c3a8/logs/screen-keystone.txt.gz#_Apr_05_16_11_27_748482 



So it looks like we need to have an uncapped release of oslo.service
before we can proceed here.


I've proposed a patch[1] to uncap eventlet in oslo.service, but it's 
failing the unit tests[2].  I'll look into it, but I thought I'd 
provide an update in the meantime.


Oh, the unit test failures are unrelated.  Apparently the unit tests 
have been failing in oslo.service for a while.  dims has a patch up at 
https://review.openstack.org/#/c/559831/ that looks to be addressing the 
problem, although it's also failing the unit tests. :-/


We finally got the uncap patch merged and a release request is up at 
https://review.openstack.org/560163.  Hopefully once that is in u-c 
we'll be past this issue.






1: https://review.openstack.org/559800
2: 
http://logs.openstack.org/00/559800/1/check/openstack-tox-py27/cef8fcb/job-output.txt.gz 



__ 


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][requirements] uncapping eventlet

2018-04-09 Thread Tony Breeds
On Mon, Apr 09, 2018 at 09:58:28AM -0400, Doug Hellmann wrote:

> Now that projects don't have to match the global requirements list
> entries exactly we should be able to remove caps from within the
> projects and keep caps in the global list for cases like this where we
> know we frequently encounter breaking changes in new releases. The
> changes to support that were part of
> https://review.openstack.org/#/c/555402/

True.  I was trying to add context to why we don't always rely on
upper-constraints.txt to save us.  So yeah we can start working towards
removing the caps per project.

Yours Tony.


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][requirements] uncapping eventlet

2018-04-09 Thread Ben Nemec



On 04/09/2018 01:12 PM, Ben Nemec wrote:



On 04/06/2018 04:02 AM, Jens Harbott wrote:

2018-04-05 19:26 GMT+00:00 Matthew Thode :

On 18-04-05 20:11:04, Graham Hayes wrote:

On 05/04/18 16:47, Matthew Thode wrote:
eventlet-0.22.1 has been out for a while now, we should try and use 
it.

Going to be fun times.

I have a review projects can depend upon if they wish to test.
https://review.openstack.org/533021


It looks like we may have an issue with oslo.service -
https://review.openstack.org/#/c/559144/ is failing gates.

Also - what is the dance for this to get merged? It doesn't look 
like we

can merge this while oslo.service has the old requirement restrictions.



The dance is as follows.

0. provide review for projects to test new eventlet version
    projects using eventlet should make backwards compat code changes at
    this time.


But this step is currently failing. Keystone doesn't even start when
eventlet-0.22.1 is installed, because loading oslo.service fails with
its pkg definition still requiring the capped eventlet:

http://logs.openstack.org/21/533021/4/check/legacy-requirements-integration-dsvm/7f7c3a8/logs/screen-keystone.txt.gz#_Apr_05_16_11_27_748482 



So it looks like we need to have an uncapped release of oslo.service
before we can proceed here.


I've proposed a patch[1] to uncap eventlet in oslo.service, but it's 
failing the unit tests[2].  I'll look into it, but I thought I'd provide 
an update in the meantime.


Oh, the unit test failures are unrelated.  Apparently the unit tests 
have been failing in oslo.service for a while.  dims has a patch up at 
https://review.openstack.org/#/c/559831/ that looks to be addressing the 
problem, although it's also failing the unit tests. :-/




1: https://review.openstack.org/559800
2: 
http://logs.openstack.org/00/559800/1/check/openstack-tox-py27/cef8fcb/job-output.txt.gz 



__
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][requirements] uncapping eventlet

2018-04-09 Thread Ben Nemec



On 04/06/2018 04:02 AM, Jens Harbott wrote:

2018-04-05 19:26 GMT+00:00 Matthew Thode :

On 18-04-05 20:11:04, Graham Hayes wrote:

On 05/04/18 16:47, Matthew Thode wrote:

eventlet-0.22.1 has been out for a while now, we should try and use it.
Going to be fun times.

I have a review projects can depend upon if they wish to test.
https://review.openstack.org/533021


It looks like we may have an issue with oslo.service -
https://review.openstack.org/#/c/559144/ is failing gates.

Also - what is the dance for this to get merged? It doesn't look like we
can merge this while oslo.service has the old requirement restrictions.



The dance is as follows.

0. provide review for projects to test new eventlet version
projects using eventlet should make backwards compat code changes at
this time.


But this step is currently failing. Keystone doesn't even start when
eventlet-0.22.1 is installed, because loading oslo.service fails with
its pkg definition still requiring the capped eventlet:

http://logs.openstack.org/21/533021/4/check/legacy-requirements-integration-dsvm/7f7c3a8/logs/screen-keystone.txt.gz#_Apr_05_16_11_27_748482

So it looks like we need to have an uncapped release of oslo.service
before we can proceed here.


I've proposed a patch[1] to uncap eventlet in oslo.service, but it's 
failing the unit tests[2].  I'll look into it, but I thought I'd provide 
an update in the meantime.


1: https://review.openstack.org/559800
2: 
http://logs.openstack.org/00/559800/1/check/openstack-tox-py27/cef8fcb/job-output.txt.gz


__
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][requirements] uncapping eventlet

2018-04-09 Thread Doug Hellmann
Excerpts from Tony Breeds's message of 2018-04-09 13:39:30 +1000:
> On Fri, Apr 06, 2018 at 09:41:07AM -0700, Clark Boylan wrote:
> 
> > My understanding of our use of upper constraints was that this should
> > (almost) always be the case for (almost) all dependencies.  We should
> > rely on constraints instead of requirements caps. Capping libs like
> > pbr or eventlet and any other that is in use globally is incredibly
> > difficult to work with when you want to uncap it because you have to
> > coordinate globally. Instead if using constraints you just bump the
> > constraint and are done.
> 
> Part of the reason that we have the caps it to prevent the tools that
> auto-generate the constraints syncs from considering these versions and
> then depending on the requirements team to strip that from the bot
> change before committing (assuming it passes CI).
> 
> Once the work Doug's doing is complete we could consider tweaking the
> tools to use a different mechanism, but that's only part of the reason
> for the caps in g-r.
> 
> Yours Tony.

Now that projects don't have to match the global requirements list
entries exactly we should be able to remove caps from within the
projects and keep caps in the global list for cases like this where we
know we frequently encounter breaking changes in new releases. The
changes to support that were part of
https://review.openstack.org/#/c/555402/

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][requirements] uncapping eventlet

2018-04-08 Thread Tony Breeds
On Fri, Apr 06, 2018 at 09:41:07AM -0700, Clark Boylan wrote:

> My understanding of our use of upper constraints was that this should
> (almost) always be the case for (almost) all dependencies.  We should
> rely on constraints instead of requirements caps. Capping libs like
> pbr or eventlet and any other that is in use globally is incredibly
> difficult to work with when you want to uncap it because you have to
> coordinate globally. Instead if using constraints you just bump the
> constraint and are done.

Part of the reason that we have the caps it to prevent the tools that
auto-generate the constraints syncs from considering these versions and
then depending on the requirements team to strip that from the bot
change before committing (assuming it passes CI).

Once the work Doug's doing is complete we could consider tweaking the
tools to use a different mechanism, but that's only part of the reason
for the caps in g-r.

Yours Tony.


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][requirements] uncapping eventlet

2018-04-06 Thread Matthew Thode
On 18-04-06 09:41:07, Clark Boylan wrote:
> On Fri, Apr 6, 2018, at 9:34 AM, Matthew Thode wrote:
> > On 18-04-06 09:02:29, Jens Harbott wrote:
> > > 2018-04-05 19:26 GMT+00:00 Matthew Thode :
> > > > On 18-04-05 20:11:04, Graham Hayes wrote:
> > > >> On 05/04/18 16:47, Matthew Thode wrote:
> > > >> > eventlet-0.22.1 has been out for a while now, we should try and use 
> > > >> > it.
> > > >> > Going to be fun times.
> > > >> >
> > > >> > I have a review projects can depend upon if they wish to test.
> > > >> > https://review.openstack.org/533021
> > > >>
> > > >> It looks like we may have an issue with oslo.service -
> > > >> https://review.openstack.org/#/c/559144/ is failing gates.
> > > >>
> > > >> Also - what is the dance for this to get merged? It doesn't look like 
> > > >> we
> > > >> can merge this while oslo.service has the old requirement restrictions.
> > > >>
> > > >
> > > > The dance is as follows.
> > > >
> > > > 0. provide review for projects to test new eventlet version
> > > >projects using eventlet should make backwards compat code changes at
> > > >this time.
> > > 
> > > But this step is currently failing. Keystone doesn't even start when
> > > eventlet-0.22.1 is installed, because loading oslo.service fails with
> > > its pkg definition still requiring the capped eventlet:
> > > 
> > > http://logs.openstack.org/21/533021/4/check/legacy-requirements-integration-dsvm/7f7c3a8/logs/screen-keystone.txt.gz#_Apr_05_16_11_27_748482
> > > 
> > > So it looks like we need to have an uncapped release of oslo.service
> > > before we can proceed here.
> > > 
> > 
> > Ya, we may have to uncap and rely on upper-constraints to keep openstack
> > gate from falling over.  The new steps would be the following:
> 
> My understanding of our use of upper constraints was that this should 
> (almost) always be the case for (almost) all dependencies.  We should rely on 
> constraints instead of requirements caps. Capping libs like pbr or eventlet 
> and any other that is in use globally is incredibly difficult to work with 
> when you want to uncap it because you have to coordinate globally. Instead if 
> using constraints you just bump the constraint and are done.
> 
> It is probably worthwhile examining if we have any other deps in the 
> situation and proactively addressing them rather than waiting for when we 
> really need to fix them.
> 

That's constantly on our list of things to do.  In the past the only
time we've capped is when we know upstream is realeasing breaking
versions and we want to hold off for a cycle or until it's fixed.  It
also has the benefit of telling consumers/packagers about something
'hard breaking'.

networkx is next on the list...

-- 
Matthew Thode (prometheanfire)


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][requirements] uncapping eventlet

2018-04-06 Thread Clark Boylan
On Fri, Apr 6, 2018, at 9:34 AM, Matthew Thode wrote:
> On 18-04-06 09:02:29, Jens Harbott wrote:
> > 2018-04-05 19:26 GMT+00:00 Matthew Thode :
> > > On 18-04-05 20:11:04, Graham Hayes wrote:
> > >> On 05/04/18 16:47, Matthew Thode wrote:
> > >> > eventlet-0.22.1 has been out for a while now, we should try and use it.
> > >> > Going to be fun times.
> > >> >
> > >> > I have a review projects can depend upon if they wish to test.
> > >> > https://review.openstack.org/533021
> > >>
> > >> It looks like we may have an issue with oslo.service -
> > >> https://review.openstack.org/#/c/559144/ is failing gates.
> > >>
> > >> Also - what is the dance for this to get merged? It doesn't look like we
> > >> can merge this while oslo.service has the old requirement restrictions.
> > >>
> > >
> > > The dance is as follows.
> > >
> > > 0. provide review for projects to test new eventlet version
> > >projects using eventlet should make backwards compat code changes at
> > >this time.
> > 
> > But this step is currently failing. Keystone doesn't even start when
> > eventlet-0.22.1 is installed, because loading oslo.service fails with
> > its pkg definition still requiring the capped eventlet:
> > 
> > http://logs.openstack.org/21/533021/4/check/legacy-requirements-integration-dsvm/7f7c3a8/logs/screen-keystone.txt.gz#_Apr_05_16_11_27_748482
> > 
> > So it looks like we need to have an uncapped release of oslo.service
> > before we can proceed here.
> > 
> 
> Ya, we may have to uncap and rely on upper-constraints to keep openstack
> gate from falling over.  The new steps would be the following:

My understanding of our use of upper constraints was that this should (almost) 
always be the case for (almost) all dependencies.  We should rely on 
constraints instead of requirements caps. Capping libs like pbr or eventlet and 
any other that is in use globally is incredibly difficult to work with when you 
want to uncap it because you have to coordinate globally. Instead if using 
constraints you just bump the constraint and are done.

It is probably worthwhile examining if we have any other deps in the situation 
and proactively addressing them rather than waiting for when we really need to 
fix them.

Clark

__
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][requirements] uncapping eventlet

2018-04-06 Thread Matthew Thode
On 18-04-06 09:02:29, Jens Harbott wrote:
> 2018-04-05 19:26 GMT+00:00 Matthew Thode :
> > On 18-04-05 20:11:04, Graham Hayes wrote:
> >> On 05/04/18 16:47, Matthew Thode wrote:
> >> > eventlet-0.22.1 has been out for a while now, we should try and use it.
> >> > Going to be fun times.
> >> >
> >> > I have a review projects can depend upon if they wish to test.
> >> > https://review.openstack.org/533021
> >>
> >> It looks like we may have an issue with oslo.service -
> >> https://review.openstack.org/#/c/559144/ is failing gates.
> >>
> >> Also - what is the dance for this to get merged? It doesn't look like we
> >> can merge this while oslo.service has the old requirement restrictions.
> >>
> >
> > The dance is as follows.
> >
> > 0. provide review for projects to test new eventlet version
> >projects using eventlet should make backwards compat code changes at
> >this time.
> 
> But this step is currently failing. Keystone doesn't even start when
> eventlet-0.22.1 is installed, because loading oslo.service fails with
> its pkg definition still requiring the capped eventlet:
> 
> http://logs.openstack.org/21/533021/4/check/legacy-requirements-integration-dsvm/7f7c3a8/logs/screen-keystone.txt.gz#_Apr_05_16_11_27_748482
> 
> So it looks like we need to have an uncapped release of oslo.service
> before we can proceed here.
> 

Ya, we may have to uncap and rely on upper-constraints to keep openstack
gate from falling over.  The new steps would be the following:

1. uncap eventlet https://review.openstack.org/559367
2. push uncapped eventlet out via requirements updates to all consumers
3. make review in requirements changing upper-constraints.txt for
   eventlet
4. projects depend on requirements change to do work on the new eventlet
   the patch generated should merge into project without the
   requirements change merged (this means the change should pass in the
   dependant review (to test 0.22.1) AND in a separate non-dependant
   review (test the current constraint).  You would merge the
   non-dependant once both reviews are passing.
5. Once some non-determined set of projects work with the new eventlet
   we'd merge the updated upper-constraint into requirements.

steps 2 and 3 can happen in parallel, projects can move to step 4 after
step 3 is done (step 2 is only needed for their project and their
project's dependencies).

There is bound to be projects that will break as they didn't take the
opportunity to fix themselves, but this should help reduce breakage.  I
suggest a 1 month deadline after step 2/3 is considered complete before
step 5 is performed.

-- 
Matthew Thode (prometheanfire)


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][requirements] uncapping eventlet

2018-04-06 Thread Jens Harbott
2018-04-05 19:26 GMT+00:00 Matthew Thode :
> On 18-04-05 20:11:04, Graham Hayes wrote:
>> On 05/04/18 16:47, Matthew Thode wrote:
>> > eventlet-0.22.1 has been out for a while now, we should try and use it.
>> > Going to be fun times.
>> >
>> > I have a review projects can depend upon if they wish to test.
>> > https://review.openstack.org/533021
>>
>> It looks like we may have an issue with oslo.service -
>> https://review.openstack.org/#/c/559144/ is failing gates.
>>
>> Also - what is the dance for this to get merged? It doesn't look like we
>> can merge this while oslo.service has the old requirement restrictions.
>>
>
> The dance is as follows.
>
> 0. provide review for projects to test new eventlet version
>projects using eventlet should make backwards compat code changes at
>this time.

But this step is currently failing. Keystone doesn't even start when
eventlet-0.22.1 is installed, because loading oslo.service fails with
its pkg definition still requiring the capped eventlet:

http://logs.openstack.org/21/533021/4/check/legacy-requirements-integration-dsvm/7f7c3a8/logs/screen-keystone.txt.gz#_Apr_05_16_11_27_748482

So it looks like we need to have an uncapped release of oslo.service
before we can proceed here.

__
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][requirements] uncapping eventlet

2018-04-05 Thread Matthew Thode
On 18-04-05 20:11:04, Graham Hayes wrote:
> On 05/04/18 16:47, Matthew Thode wrote:
> > eventlet-0.22.1 has been out for a while now, we should try and use it.
> > Going to be fun times.
> > 
> > I have a review projects can depend upon if they wish to test.
> > https://review.openstack.org/533021
> 
> It looks like we may have an issue with oslo.service -
> https://review.openstack.org/#/c/559144/ is failing gates.
> 
> Also - what is the dance for this to get merged? It doesn't look like we
> can merge this while oslo.service has the old requirement restrictions.
> 

The dance is as follows.

0. provide review for projects to test new eventlet version
   projects using eventlet should make backwards compat code changes at
   this time.
1. uncap requirements for eventlet (do not raise upper constraint)
   step 0 does not have to be done for this to occur, but it'd be nice.
2. make sure all projects in projects.txt uncap eventlet (this is harder
   now that we have per-project requirements)
3. raise the constraint for eventlet, optionally also raise the global
   requirement for it as well

-- 
Matthew Thode (prometheanfire)


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][requirements] uncapping eventlet

2018-04-05 Thread Graham Hayes
On 05/04/18 16:47, Matthew Thode wrote:
> eventlet-0.22.1 has been out for a while now, we should try and use it.
> Going to be fun times.
> 
> I have a review projects can depend upon if they wish to test.
> https://review.openstack.org/533021

It looks like we may have an issue with oslo.service -
https://review.openstack.org/#/c/559144/ is failing gates.

Also - what is the dance for this to get merged? It doesn't look like we
can merge this while oslo.service has the old requirement restrictions.

> 
> 
> __
> 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][requirements] uncapping eventlet

2018-04-05 Thread Matthew Thode
eventlet-0.22.1 has been out for a while now, we should try and use it.
Going to be fun times.

I have a review projects can depend upon if they wish to test.
https://review.openstack.org/533021
-- 
Matthew Thode (prometheanfire)


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