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 <prometheanf...@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
OpenStack Development Mailing List (not for usage questions)