Re: [openstack-dev] [Openstack-operators] How are consumers/operators new to openstack supposed to know about upper-constraints?

2016-02-16 Thread Ian Cordasco 
On Feb 16, 2016 11:04 AM, "Sean Dague"  wrote:
>
> On 02/16/2016 11:48 AM, Ian Cordasco wrote:
> >
> >
> > -Original Message-
> > From: Matt Riedemann 
> > Reply: Matt Riedemann 
> > 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

> > 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

Re: [openstack-dev] [Openstack-operators] How are consumers/operators new to openstack supposed to know about upper-constraints?

2016-02-16 Thread Sean Dague 
On 02/16/2016 11:48 AM, Ian Cordasco wrote:
>  
> 
> -Original Message-
> From: Matt Riedemann 
> Reply: Matt Riedemann 
> Date: February 16, 2016 at 09:30:49
> To: OpenStack Development Mailing List (not for usage questions) 
> , 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'.

-Sean

-- 
Sean Dague
http://dague.net

__
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