Open Stack

On Feb 16, 2016 11:04 AM, "Sean Dague" <sean at dague.net> wrote:
>
> On 02/16/2016 11:48 AM, Ian Cordasco wrote:
> >
> >
> > -----Original Message-----
> > From: Matt Riedemann <mriedem at linux.vnet.ibm.com>
> > Reply: Matt Riedemann <mriedem at linux.vnet.ibm.com>
> > Date: February 16, 2016 at 09:30:49
> > To: OpenStack Development Mailing List (not for usage questions) <
openstack-dev at lists.openstack.org>, openstack-operators at lists.openstack.org
<openstack-operators at 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. ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160216/46a34221/attachment.html>