On Thu, Dec 14, 2017 at 10:37 AM, Doug Hellmann <d...@doughellmann.com> wrote: > What would our world look like if we treated inter-service dependencies like > we do service-to-library dependencies and only integration test released > components, rather than installing everything from source by default?
I've been struggling to catch up and haven't gotten through the office hours log yet, but this summarizes the thing that keeps bounding through my mind. But it seems to me that much of the reaction to ttx's proposal gets into things that are not directly development-cycle-related. It feels like we are continuing to treat symptoms and not actually address root causes. I think #1 on our top-wanted list for the Board needs to be to address these root causes. Continuing to not do this will become an existential problem for OpenStack. Look at the situation with Nova and the amount of energy spent on trying to improve things there without actually being able to address the real problems. Some of these problems are structural to the software, some of them are the massive amount of inertia that a 6 year old project that needs to be backward-compatible inevitably carries. The dev cycle discussion is (to pick a number) 80% focused on the problems related to Nova: upgrade times, release deployment time, etc. Clint brought up Swift earlier in the thread, and I think that is the counter-example of what can happen with well-defined interfaces and stable APIs. Swift has been successful from the start with their release model and fitting it into the overall OpenStack releases. Why? Because it does one thing, does it damn well, and does it with a VERY stable API. Some of the newer projects have also been able to operate in this mode. Even with the differences in how they were created, Cinder and Neutron are still tightly tied to Nova in terms of upgrades and the requirements to keep them coordinated in specifically controlled releases. Outside of those three projects, what others are experiencing the sorts of problems being discussed here? Is this (mostly) only a problem the three largest and tightly-coupled projects? In the current environment I do not see any of our corporate sponsors stepping up to un-couple those three, but for the rest it seems like Doug's suggestion goes a long way toward addressing problems being brought up here. dt -- Dean Troyer dtro...@gmail.com __________________________________________________________________________ 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