Open Stack

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 <prometheanfire at gentoo.org>:
> > > > 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180406/d458eb8a/attachment.sig>