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