Open Stack

On 12/14/2017 11:12 AM, Dean Troyer wrote:
> On Thu, Dec 14, 2017 at 10:37 AM, Doug Hellmann <doug at 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