Open Stack

On Thu, Jul 11, 2013 at 7:01 AM, Sean Dague <sean at dague.net> wrote:

> On 07/11/2013 08:48 AM, John Griffith wrote:
>
>>
>>
>>
>> On Thu, Jul 11, 2013 at 6:29 AM, Dirk Müller <dirk at dmllr.de
>> <mailto:dirk at dmllr.de>> wrote:
>>
>>     Hi Sean,
>>
>>      > Cinder uncapping python-keystoneclient will get us past this.
>>
>>     There is a review exactly proposing that:
>>
>>     https://review.openstack.org/#**/c/36344/<https://review.openstack.org/#/c/36344/>
>>
>>
>> Actually for a number of reasons:
>> https://review.openstack.org/#**/c/36559/<https://review.openstack.org/#/c/36559/>is what we needed,
>> which I gave up on last night a bit after midnight when James Blair moved
>> it
>> to the front of the queue and it encountered a hiccup, at which point
>> some other
>> core Cinder folks took over baby-sitting it and it's finally through.
>>
>>
>>
>>
>>      > Though I'm not
>>      > quite sure how we got to this break point in the first place.
>>
>>
>>     I think this is due to the django_openstack_auth breakage that let
>>     this one slip by (there was for a short amount of time a >= 0.3
>>     requirement on python-keystoneclient from somewhere).
>>
>> Yep, although it wasn't that short of a period of time.  I also raised
>> this concern
>> over the ML regarding common-requirements etc and had ZERO response.
>>
>
> I think the issue is that it came in the fire drill when we were running
> around getting to the bottom of the last gate fail.... sorry.
>

Didn't mean it in that way at all... my message my not have been clear
anyway.

>
> I guess I thought my full uncapping strategy might supercede just a sync
> issue, no?


To be honest and try to recap my opinion on this I don't really care at all
how it's done, but:
I *thought* the whole point of the common-requirements deal was to have
EVERYBODY on the same page
and avoid this very situation.

However it turned out a number of projects were out of sync earlier this
week so we headed in to a
a bit of a death spiral.  And the change that bumped it... I haven't looked
back to figure out how
exactly that made it in to begin with but I assume it was done by something
like NOT using the
requirements file to install the client or something?  This is all I can
figure because when I first
noticed that things were out of sync on Monday I thought *ok, I'll just
remove the upper bound on Cinder
to match the other projects since we're ignoring common-requirements*.
 That didn't work because as it
turns out we DO in fact have enforcement if you try and change your
requirements file in a project and
it doesn't match what's in the common file (a good thing in my opinion).

So I sent the email regarding the state of things... then yesterday as
everybody noticed things fell apart
when the common-requirements file was updated BUT Cinder was not updated to
match (makes sense right).  So
you think *sure, update common, no go update cinder etc*, well in theory
that's great but with everything
going on yesterday the average time to get a patch in was somewhere around
2 hours or something and throw in
our favorite gating bug of the month (bug 1194026, which now has over 125
rechecks when combined with it's duplicate)
and it didn't take 12 hours to get the change in, it took closer to 20
hours.

Obviously there's an opportunity here.  Whether that's taking all of the
requirements version information and having it ONLY
come from the common-requirements file or uncapping or whatever everybody
else wants to do I don't really care it just
needs to be addressed.

My proposal would be each projects requirements file is used as nothing
more than a list of the packages it needs/wants,
the common-requirements file is what's used to determine version to install
and is where the actual install work is done,
removing upper bounds could save a lot of issues as well, but I think there
could be some consequences there as well.


>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/f02c8989/attachment.html>