<div dir="ltr"><div>Hey Christian,</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Jay Faulkner</div><div>Ironic PTL</div><div>TC Vice-Chair<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 11, 2023 at 12:02 PM Christian Rohmann <<a href="mailto:christian.rohmann@inovex.de">christian.rohmann@inovex.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 11/05/2023 15:54, Julia Kreger wrote:<br>
> Awesome! Thanks for the prompt reply and action on a patch for <br>
> Neutron. The test patch proposed against Ironic passed, which is <br>
> definitely a good sign!<br>
<br>
While it's really cool to see how quickly this PostgreSQL issue was <br>
fixed for Ironic, I believe there is no widespread testing and <br>
validation of PostgreSQL for other projects (anymore).<br>
<br>
There even was an official communication from the TC in 2017 about not <br>
"supporting" anything but MySQL / MariaDB:<br>
<a href="https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.html" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.html</a><br>
<br>
I myself ran into multiple issues, some during schema upgrades and some <br>
only at runtime because certain side-effect such as improper booleans or <br>
"free solo SQL"<br>
where used within the code, rendering the ORM abstraction of the <br>
actually used DBMS useless. This is also making it very hard to fully <br>
validate the DBMS is interchangeable<br>
without particularly testing for those kind of cases in all sorts of <br>
database fields or by doing code reviews.<br>
<br>
<br>
What I am saying is, that as a an operator I appreciate clear <br>
communication and clear deprecation processes over "best-effort" <br>
commitments.<br>
It does not help if there is a minefield of issues and raised bugs about <br>
incompatibilities are not considered really important since the <br>
user-base for PostgreSQL installs has diminished.<br>
<br>
If I use a set of services just fine, but as soon as I add another OS <br>
project to my cloud I could run into all sorts of problems, just because <br>
I chose the "wrong" DBMS.<br>
<br>
<br>
<br>
Regards<br>
<br>
Christian<br>
<br>
<br>
</blockquote></div>