Open Stack

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 at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230511/a1e233bb/attachment.htm>