Open Stack

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

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud