On Feb 16, 2016 11:04 AM, "Sean Dague" <s...@dague.net> wrote: > > On 02/16/2016 11:48 AM, Ian Cordasco wrote: > > > > > > -----Original Message----- > > From: Matt Riedemann <mrie...@linux.vnet.ibm.com> > > Reply: Matt Riedemann <mrie...@linux.vnet.ibm.com> > > Date: February 16, 2016 at 09:30:49 > > To: OpenStack Development Mailing List (not for usage questions) < openstack-dev@lists.openstack.org>, openstack-operat...@lists.openstack.org <openstack-operat...@lists.openstack.org> > > Subject: [Openstack-operators] How are consumers/operators new to openstack supposed to know about upper-constraints? > > > >> We have a team just upgrading to Liberty and they are having problems. > >> While running down their list of packages they are using, I noticed they > >> have os-brick 0.8.0 which is the latest version (from mitaka). > >> > >> However, os-brick in stable/liberty upper-constraints is at 0.6.0 [1]. > >> > >> So while I don't think their immediate problems are due to using an > >> untested version of os-brick on stable/liberty, they are obviously just > >> picking up the latest versions of dependencies because they aren't > >> capped in requirements. That could eventually bite them because there > >> are things that don't work together in liberty depending on what > >> versions you have [2]. > >> > >> My main question is, how are we expecting consumers/deployers of > >> openstack to know about the upper-constraints file? Where is that > >> advertised in the manuals? > >> > >> There is nothing in the Liberty release notes [3]. > >> > >> I'm sure there is probably something in the openstack/requirements repo > >> devref, but I wouldn't expect a deployer to know that repo exists let > >> alone to go off and read it's docs and understand how it applies to them > >> (a lot of openstack developers probably don't know about the reqs repo > >> or what it does). > >> > >> Does the operator community have any tips or know something that I > >> don't? I think ops people that have been around awhile are just aware > >> because it's been coming for a few releases now so they are aware of the > >> magical unicorn and have sought out info on it, but what about new > >> deployments? > >> > >> [1] > >> https://github.com/openstack/requirements/blob/0e8a4136b4e9e91293d46b99879c966e3bddd9bd/upper-constraints.txt#L181 > >> [2] https://bugs.launchpad.net/oslo.service/+bug/1529594 > >> [3] https://wiki.openstack.org/wiki/ReleaseNotes/Liberty > > > > This is actually a good question. I think some assumptions were made about how people are deploying OpenStack. I think those assumptions are along the lines of: > > > > - Operators are deploying with downstream packages (from Ubuntu, Red Hat, etc.) > > - Operators are using something like the Chef Cookbooks, Puppet Modules, or the Ansible Playbooks that ideally handle all of this for them. > > > > I know OpenStack Ansible takes upper-constraints into consideration when it's building wheel repositories for dependencies. I would guess that the other deployment projects do something similar or also rest upon the usage of downstream packages. I think we (the developers) tend to think that anyone not using downstream packages is doing it wrong since they handle dependency management for us (as presented to the end user). > > > > I'm not sure what the right solution will be because I would be surprised if some more explicit form of upper-constraints present in requirements of each project would be argued against as too much work/specificity. > > Also, churn. We got rid of this model of narrow ranges in repositories > for a reason, because it very quickly turns into an incompatible > collision between projects / libraries. Maybe if this only applied to > top level projects which could never be imported by others it would be > ok, I don't know. > > > I also think this clearly demonstrates why upper caps (although painful) are at least informational even when we have upper-constraints protecting the gates. > > I think due to the limitations on pip and python packaging we've largely > said (maybe too implictly) that you have to have an installer layer in > OpenStack, and it has to understand requirements at the install layer. > > That might be distro packages. That might be any of the install projects > in the big tent (chef, puppet, ansible, fuel). That might be devstack. > But it's definitely something between you and 'pip install nova'.
Ignoring, of course, the fact that unless you're taking the ansible approach "pip install nova" wouldn't ever work. ;-)
__________________________________________________________________________ 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