On 18 April 2016 at 03:13, Doug Hellmann <d...@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 <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
