Open Stack

On Mon, Feb 16, 2015, at 01:01 PM, Ian Cordasco wrote:
> Hey everyone,
> 
> The os-ansible-deployment team was working on updates to add support for
> the latest version of juno and noticed some interesting version
> specifiers
> introduced into global-requirements.txt in January. It introduced some
> version specifiers that seem a bit impossible like the one for requests
> [1]. There are others that equate presently to pinning the versions of
> the
> packages [2, 3, 4].
> 
> I understand fully and support the commit because of how it improves
> pretty much everyone’s quality of life (no fires to put out in the middle
> of the night on the weekend). I’m also aware that a lot of the downstream
> redistributors tend to work from global-requirements.txt when determining
> what to package/support.
> 
> It seems to me like there’s room to clean up some of these requirements
> to
> make them far more explicit and less misleading to the human eye (even
> though tooling like pip can easily parse/understand these).

I think that's the idea. These requirements were generated
automatically, and fixed issues that were holding back several projects.
Now we can apply updates to them by hand, to either move the lower
bounds down (as in the case Ihar pointed out with stevedore) or clean up
the range definitions. We should not raise the limits of any Oslo
libraries, and we should consider raising the limits of third-party
libraries very carefully.

We should make those changes on one library at a time, so we can see
what effect each change has on the other requirements.

> 
> I also understand that stable-maint may want to occasionally bump the
> caps
> to see if newer versions will not break everything, so what is the right
> way forward? What is the best way to both maintain a stable branch with
> known working dependencies while helping out those who do so much work
> for
> us (downstream and stable-maint) and not permanently pinning to certain
> working versions?

Managing the upper bounds is still under discussion. Sean pointed out
that we might want hard caps so that updates to stable branch were
explicit. I can see either side of that argument and am still on the
fence about the best approach.

> 
> I’ve CC’d -operators too since I think their input will be invaluable on
> this as well (since I doubt everyone is using distro packages and some
> may
> be doing source-based installations).

I've not copied the operators list, since we try not to cross-post
threads. We should ask them to respond here on the dev list, or maybe
someone can summarize any responses from the other list.

Doug

> 
> Cheers,
> Ian
> 
> [1]: 
> https://github.com/openstack/requirements/commit/499db6b64071c2afa16390ad2b
> c024e6a96db4ff#diff-d7d5c6fa7118ea10d88f3afeaef4da77R126
> [2]: 
> https://github.com/openstack/requirements/commit/499db6b64071c2afa16390ad2b
> c024e6a96db4ff#diff-d7d5c6fa7118ea10d88f3afeaef4da77R128
> [3]: 
> https://github.com/openstack/requirements/commit/499db6b64071c2afa16390ad2b
> c024e6a96db4ff#diff-d7d5c6fa7118ea10d88f3afeaef4da77R70
> [4]: 
> https://github.com/openstack/requirements/commit/499db6b64071c2afa16390ad2b
> c024e6a96db4ff#diff-d7d5c6fa7118ea10d88f3afeaef4da77R189
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev