Hi Vladimir,

This is something that I’ve been looking at lately, I’ve recently started to build the following service operator for OpenStack:

https://github.com/vexxhost/openstack-service-operator

It supports endpoints and services right now, I want to try and see what it looks like to replace the keystone jobs by this and do users next. There’s also other things like for example the image uploads being managed as Kubernetes jobs. I’d love it to be in a world where a db-sync is the only job we have.

The goal of the service operator is to be a bit more generic, I’m thinking even the Cluster API could take advantage of something like this similar to how Azure takes advantage of their Azure Service Operator for machines.

Thanks, Mohammed

From: Vladimir Kozhukalov kozhukalov@gmail.com Date: Friday, July 5, 2024 at 6:39 PM To: Mohammed Naser mnaser@vexxhost.com Cc: OpenStack Discuss openstack-discuss@lists.openstack.org Subject: Re: [openstack-helm] SQLAlchemy 2.0 support You don't often get email from kozhukalov@gmail.com. Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification Hi Mohammed,

Thanks a lot for reporting the bug. IMO at this point it is much easier to fix the db-init script and make it compatible with SQLAlchemy 2.0. I'll take care of this.

It is interesting that a couple days ago there was a small discussion in the #openstack-helm Slack chat about utilizing CRs when bootstrapping the deployments (specifically we discussed creating Keystone users). My first impression about this was that it is kinda a layer violation when you try to create such entities not directly but via K8s API. But it looks like there are cases when having this kind of simple operator for managing databases/users/keyrings could bring convenience. One of our users mentioned the Keystone federation case when some customization is necessary and using CRs is much easier than modifying the Keystone init script in the helm-tooking chart.

We also had a similar case when we switched to Rook managed Ceph clusters by default. We introduced the ceph-adapter-rook chart that creates Ceph keyrings/configs, but probably the operator would be more convenient here.

So, taking into account that this is not the first time this topic (OSH operator) has come up recently we could try to go this way. Let's maybe implement a POC for the start and then gather opinions.

On Fri, Jul 5, 2024 at 1:40 PM Mohammed Naser <mnaser@vexxhost.commailto:mnaser@vexxhost.com> wrote: Hi everyone!

It seems like our db-init jobs are broken with the latest version of OpenStack because it doesn’t work with SQLAlchemy 2.0

2024-05-31 03:21:34,290 - OpenStack-Helm DB Init - INFO - Got DB root connection 2024-05-31 03:21:34,290 - OpenStack-Helm DB Init - INFO - Using /etc/keystone/keystone.conf as db config source 2024-05-31 03:21:34,292 - OpenStack-Helm DB Init - INFO - Trying to load db config from database:connection 2024-05-31 03:21:34,292 - OpenStack-Helm DB Init - INFO - Got config from /etc/keystone/keystone.conf 2024-05-31 03:21:34,331 - OpenStack-Helm DB Init - INFO - Tested connection to DB @ percona-xtradb-haproxy.openstack.svc.cluster.local:3306 as root 2024-05-31 03:21:34,332 - OpenStack-Helm DB Init - INFO - Got user db config 2024-05-31 03:21:34,332 - OpenStack-Helm DB Init - CRITICAL - Could not create database keystone Traceback (most recent call last): File "/tmp/db-init.py", line 112, in <module> root_engine.execute("CREATE DATABASE IF NOT EXISTS {0}".format(database)) AttributeError: 'Engine' object has no attribute 'execute'

I was wondering if it makes sense to fix this, or if this is something that we should just take the time to simply replace with some sort of simple operator that creates manages/watches database CRs (if one doesn’t exist?)

Thanks Mohammed

-- Best regards, Kozhukalov Vladimir