As OpenStack has evolved and grown, we are ending up with more and more
MySQL-isms in the code. I'd love to see OpenStack support every database
out there, but that is becoming more and more difficult. I've tried to
get OpenStack to work with other databases like Oracle DB, MongoDB,
TimesTen, NoSQL, and I can tell you that first hand it's not doable
without making some significant changes. Some services would be easy to
make more database agnostic, but most would require a lot of reworking.
I think the pragmatic thing is to do is focus on supporting the MySQL
dialect with the different engines and clustering technologies that have
emerged. oslo_db is a great abstraction layer. We should continue to
build upon that and make sure that every OpenStack service uses it
end-to-end. I've already seen plenty of cases where services like
Barbican and Murano are not using it. I've also seen plenty of use cases
where core services are using the older methods of connecting to the
database and re-inventing the wheel to deal with things like retries.
The more we use oslo_db and make sure that people are consistent with
it's use and best practices, we better off we'll be in the long-run.
On the topic of doing live upgrades. I think it's a "nice to have"
feature, but again we need a consistent framework that all services will
follow. It's already complicated enough with how different services deal
with parallelism and locking. So if we are going to go down this path
across even the core services, we need to have a solid solution and
framework. Otherwise, we'll end up with a hodgepodge of maturity levels
between services. The expectation from operators is that if you say you
can do live upgrades, they will expect that to be the case across all of
OpenStack and not a buffet style feature. We would also have to take
into consideration larger shops that have more distributed and
scaled-out control planes. So we need be careful on this as it will have
a wide impact on development, testing, and operating.
Octave
On 5/23/2017 6:00 AM, Sean Dague wrote:
On 05/22/2017 11:26 PM, Matt Riedemann wrote:
On 5/22/2017 10:58 AM, Sean Dague wrote:
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.
I think this is reasonable and is what I've been hoping for as a result
of the feedback on this.
I think it's totally fine to say tier 1 backends get shiny new features.
I mean, hell, compare the libvirt driver in nova to all other virt
drivers in nova. New features are written for the libvirt driver and we
have to strong-arm them into other drivers for a compatibility story.
I think we should turn on postgresql as a backend in one of the CI jobs,
as I've noted in the governance change - it could be the nova-next
non-voting job which only runs on nova, but we should have something
testing this as long as it's around, especially given how easy it is to
turn this on in upstream CI (it's flipping a devstack variable).
Postgresql support shouldn't be in devstack. If we're taking a tier 2
approach, someone needs to carve out database plugins from devstack and
pg would be one (as could be galera, etc).
This historical artifact that pg was maintained in devstack, but much
more widely used backends were not, is part of the issue.
It would also be a good unit test case as to whether there are pg
focused folks around out there willing to do this basic devstack plugin
/ job setup work.
-Sean
__________________________________________________________________________
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
