Open Stack

On 05/15/2017 07:16 AM, Sean Dague wrote:
> We had a forum session in Boston on Postgresql and out of that agreed to
> the following steps forward:
> 
> 1. explicitly warn in operator facing documentation that Postgresql is
> less supported than MySQL. This was deemed better than just removing
> documentation, because when people see Postgresql files in tree they'll
> make assumptions (at least one set of operators did).
> 
> 2. Suse is in process of investigating migration from PG to Gallera for
> future versions of their OpenStack product. They'll make their findings
> and tooling open to help determine how burdensome this kind of
> transition would be for folks.
> 
> After those findings, we can come back with any next steps (or just
> leave it as good enough there).
> 
> The TC governance patch is updated here -
> https://review.openstack.org/#/c/427880/ - or if there are other
> discussion questions feel free to respond to this thread.

I've ended up in a number of conversations publicly and privately over
the last week. I'm trying to figure out how we best capture and
acknowledge the concerns.

My top concerns remain:

A1) Do not surprise users late by them only finding out they are on the
less traveled once they are so deeply committed there is no turning
back. It's fine for users to choose that path as long as they are
informed that they are going to need to be more self reliant.

A2) Do not prevent features like zero downtime keystone making forward
progress with a MySQL only solution. There will always be a way to
handle these things with a change window, but the non change window
version really does need more understanding of what the db is doing.

There are some orthogonal concerns

B1) PG was chosen by people in the past, maybe more than we realized,
that's real users that we don't want to throw under a bus. Whole sale
delete is off the table. Even what deprecation might mean is hard to
figure out given that there is "no clear path off", "missing data of
who's on it", and potentially creative solutions using it that people
would like (the Cockroach db question, though given some of the Galera
fixes that have had to go in, these things are never drop in replacements).

B2) The upstream code isn't so irreparably changed (e.g. delete the SQLA
layer) that it's not possible to have alternative DB backends
(especially as people might want to experiement with different
approaches in the future).


I think these are actually compatible concerns. The current proposal to
me actually tries to address A1 & B1, with a hint about why A2 is
valuable and we would want to do that.

It feels like there would be a valuable follow on in which A2 & B2 were
addressed which is basically "progressive enhancements can be allowed to
only work with MySQL based backends". Which is the bit that Monty has
been pushing for in other threads.

This feels like what a Tier 2 support looks like. A basic SQLA and pray
so that if you live behind SQLA you are probably fine (though not
tested), and then test and advanced feature roll out on a single
platform. Any of that work might port to other platforms over time, but
we don't want to make that table stakes for enhancements.

	-Sean


-- 
Sean Dague
http://dague.net