On 12/14/2017 11:12 AM, Dean Troyer wrote:
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.
Can you give some specific examples here? What are we spending massive
amounts of time on that aren't addressing real problems? What are the
real problems that the Nova team is not working on and apparently is a
priority to everyone else in the OpenStack ecosystem but we are somehow
oblivious?
The dev cycle discussion is (to pick a number) 80% focused on the
problems related to Nova: upgrade times, release deployment time, etc.
Again, specific examples please. Is Nova somehow breaking compatibility
every other week which is making upgrade impossible? I'm under the
impression, maybe wrongly so, that the Nova team bends over backward
trying to make sure we don't screw people doing upgrades as much as we
can, at least across N-1 release boundaries. This is why we have
microversions in the API. This is why we put in blocker schema
migrations so that you can't move forward until you've performed online
data migrations. Remember online data migrations? That's the thing where
you don't have your control plane down for 8 hours running "nova-manage
db sync". Writing code that migrates date at runtime across multiple
cells and databases is not fun. If we're doing that for no apparent
benefit, then we should stop I guess.
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.
What is unstable about the compute API (assuming Nova is guilty of
having unstable APIs here)?
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.
I said this elsewhere in this thread, but how so? You can definitely run
mixed versions of these services as they communicate over REST APIs.
Cinder and Nova are using microversions. Neutron isn't, but uses API
extensions to indicate if a feature is available in the API or not,
which Nova leverages. The shared library thing I get, but hasn't that
been a solved problem for years now (run the services in venvs,
containers, etc)? What specifically keeps people from being able to run
old Nova and newer Cinder/Neutron and vice-versa?
--
Thanks,
Matt
__________________________________________________________________________
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
