Open Stack

On 18 April 2016 at 03:13, Doug Hellmann <doug at doughellmann.com> wrote:
> I am organizing a summit session for the cross-project track to
> (re)consider how we manage our list of global dependencies [1].
> Some of the changes I propose would have a big impact, and so I
> want to ensure everyone doing packaging work for distros is available
> for the discussion. Please review the etherpad [2] and pass the
> information along to colleagues who might be interested.


Thanks for kicking this off Doug. Its a great topic - as the thread shows :).

I have a few thoughts - and I fully intend to be at the session as
well. I don't know if I'm pro or con the specific proposal today - and
I definitely need to understand the details of the issue a bit better,
my focus has been on various testing and packaging things for a bit -
I've neglected my requirements reviews except when prompted - sorry.

I think that federated constraints/requirements raise some risks with
multi-project gating jobs. This is separate to the co-installability
requirement and instead due to the ability to end up with a multi-tree
wedge. If something happens atomically that breaks two projects
constraints at the same time, two distinct git changes are required to
fix that. AIUI this happens maybe 1/8 weeks? In a centralised model we
can fix that atomically within the normal CI workflow. With a
federated approach, we will have to get infra intervention. Similarly,
if there is a needle-threading situation that can end up with multiple
projects broken at the same time, and they consume each other (or both
are present in devstack jobs for the other) we can wedge. I'm thinking
e.g. changes to Nova and Neutron go through, independently but the
combination turns out to be API incompatible on the callbacks between
services or some such. Perhaps too niche to worry about?

Co-installability has very significant impact on the backwards compat
discussion: its a major driver of the need I perceive for library
backwards compatibility (outside of client library compat with older
clouds) and I for one think we could make a bunch of stuff simpler
with a reduced co-installability story.
https://review.openstack.org/#/c/226157/ and
https://etherpad.openstack.org/p/newton-backwards-compat-libs

I'm super worried about the impact on legacy distributions though - I
don't think they're ready for it, and I don't think we're important
enough to act as a sane forcing function: but perhaps we can find some
compromise that works for everyone - or at least get distros to commit
to moving ahead in their view of the world :).

I don't think we can ditch co-installability per se though, even in a
totally containerised world: we still have the need to make each leaf
artifact in the dependency tree co-installable with all its
dependencies. That is, we can't get to a situation where
oslo.messaging and oslo.db are not co-installable, even though they
don't depend on each other, because Nova depends on both and we want
to be able to actually install Nova.

-Rob


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