Open Stack

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