On Thu, Jul 11, 2013 at 7:01 AM, Sean Dague <[email protected]> wrote: > On 07/11/2013 08:48 AM, John Griffith wrote: > >> >> >> >> On Thu, Jul 11, 2013 at 6:29 AM, Dirk Müller <[email protected] >> <mailto:[email protected]>> 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 > [email protected].**org <[email protected]> > http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
