On 01/10/2014 04:13 AM, Robert Collins wrote:
On 5 January 2014 02:02, Sean Dague <s...@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
s...@dague.net / sean.da...@samsung.com
http://dague.net
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
