Open Stack

On 01/10/2014 04:13 AM, Robert Collins wrote:
> On 5 January 2014 02:02, Sean Dague <sean at dague.net> wrote:
>
>> So we used to do that the apps against release libraries. And the result was
>> more and more full day gate breaks. We did 2 consecutive ones in 2 weeks.
>>
>> Basically, once you get to be a certain level of coupled in OpenStack we can
>> no longer let you manage your own requirements file. We need a global lever
>> on it. Because people were doing it wrong, and slowly (we could go through
>> specific examples about how bad this was. This was a top issue at nearly
>> every summit I'd been at going back to Essex.
>> ..
>> (It was about 14 days to resolve the python client issue, there was a django
>> issue around the same time that never made it to the list, as we did it all
>> under fire in IRC)
>>
>> And we have a solution now. Which is one list of requirements that we can
>> test everything with, that we can propose requirements updates
>> speculatively, and see what works and what doesn't. And *after* we know they
>> work, we propose the changes back into the projects, now automatically.
>
> So the flip-flop thing is certainly very interesting. We wouldn't want
> that to happen again.
>
>>> I do see the issue Sean is pointing at, which is that we have to fix
>>> the libraries first and then the things that use them. OTOH thats
>>> normal in the software world, I don't see anything unique about it.
>>
>>
>> Well, as the person that normally gets stuck figuring this out when .eu has
>> been gate blocked for a day, and I'm one of the first people up on the east
>> coast, I find the normal state of affairs unsatisfying. :)
>
> :)
>
>> I also think that what we are basically dealing with is the classical N^2
>> comms problem. With N git trees that we need to all get working together,
>> this gets exponentially more difficult over time. Which is why we created
>> the integrated gate and the global requirements lever.
>
> I don't think we are - I think we're dealing with the fact that we've
> had no signal - no backpressure - on projects that have upper caps set
> to remove those caps. So they stick there and we all suffer.
>
>> Another solution would be reduce the number of OpenStack git trees to make
>> N^2 more manageable, and let us with single commits affect multiple
>> components. But that's not the direction we've taken.
>
> I don't think thats necessary.
>
> What I'd like to see is:
> A) two test sets for every commit:
>   - commit with latest-release of all deps
>   - commit with latest-trunk [or dependent zuul ref] of all deps
>
> B) *if* there are upper version caps for any reason, some signal back
> to developers that this exists and that we need to fix our code to
> work with that newer release.
>    - Possibly we should allow major version caps where major releases
> are anticipated to be incompatible without warning about that *until*
> there is a [pre-]release of the new major version available

Honestly, I would too. I actually proposed just this at Summit. :) But 
it's a ton of work, that is lacking for volunteers right now. Earliest 
I'm going to look at it is Juno, but I'm not really sure I can really 
commit on this one. And I expect this all by itself needs two or three 
people where this is a top priority.

So consider this a call for volunteers. If you want to be an OpenStack 
hero, here is a great way to do so.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net