Hey Christian,

You're 100% correct to use resolutions from the TC and governance policies to help you determine what is officially supported for an integrated OpenStack release. However, these guidelines, from a project perspective, are minimums. Many projects; Ironic included, run jobs to ensure postgresql support continues working. This is absolutely best-effort, and I believe is mostly grown out of trying to continue to support operators who made the choice to use postgresql. With my Ironic PTL hat on, I appreciate that we explicitly ensure we're not limiting our project to a single DBMS forever.

We test Ironic against the following DBMS: mysql/mariadb (used by most users), postgresql, and sqlite (used by metal3, primarily). In the case of postgresql (as mentioned in this thread), we test more than Ironic, we ensure a full deployment is possible which tests the basic functionality of Ironic, Neutron, Nova, and many other projects. This doesn't mean postgresql or sqlite is supported from the perspective of an integrated OpenStack install, but it's there and available to use for deployers who might choose to use Ironic standalone (metal3/bifrost) or for operators with clouds that predate OpenStack's statement of non-support for postgres.

I apologize if this appears inconsistent from the outside, but we want to continue to serve as many use cases as possible -- sometimes that means going above and beyond the minimum supported platforms.

Thanks,

Jay Faulkner

Ironic PTL

TC Vice-Chair

On Thu, May 11, 2023 at 12:02 PM Christian Rohmann <christian.rohmann@inovex.de> wrote:

On 11/05/2023 15:54, Julia Kreger wrote:
> Awesome! Thanks for the prompt reply and action on a patch for
> Neutron. The test patch proposed against Ironic passed, which is
> definitely a good sign!

While it's really cool to see how quickly this PostgreSQL issue was
fixed for Ironic, I believe there is no widespread testing and
validation of PostgreSQL for other projects (anymore).

There even was an official communication from the TC in 2017 about not
"supporting" anything but MySQL / MariaDB:
https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.html

I myself ran into multiple issues, some during schema upgrades and some
only at runtime because certain side-effect such as improper booleans or
"free solo SQL"
where used within the code, rendering the ORM abstraction of the
actually used DBMS useless. This is also making it very hard to fully
validate the DBMS is interchangeable
without particularly testing for those kind of cases in all sorts of
database fields or by doing code reviews.

What I am saying is, that as a an operator I appreciate clear
communication and clear deprecation processes over "best-effort"
commitments.
It does not help if there is a minefield of issues and raised bugs about
incompatibilities are not considered really important since the
user-base for PostgreSQL installs has diminished.

If I use a set of services just fine, but as soon as I add another OS
project to my cloud I could run into all sorts of problems, just because
I chose the "wrong" DBMS.

Regards

Christian