Skip to content

OpenStack Helm

The UnderStack project utilizes OpenStack Helm for many OpenStack
components, however we prefer to utilize upstream provided operators
for infrastructure components. The OpenStack Helm project has
started to use some of them but has not fully embraced them yet.

MariaDB

By utilizing the MariaDB operator we're able to avoid the need
to run the db-init and db-drop jobs by utilizing the
correct operator resources.

apiVersion: k8s.mariadb.com/v1alpha1
kind: Database
---
apiVersion: k8s.mariadb.com/v1alpha1
kind: User
---
apiVersion: k8s.mariadb.com/v1alpha1
kind: Grant

The above resources, when configured do the following:

  • create a database
  • create a user
  • grant permissions to a user on a database

Which is exactly what the db-init script does when executed
as a job. When these resources are deleted, the reverse operations
happen which is what the db-drop script does. Lastly as these
scripts aren't used the associated DB_CONNECTION secret value isn't
necessary allowing us to disable the secret_db manifest.

More importantly, these two jobs rely on proper ordering via
Helm Chart Hooks which isn't
necessarily friendly towards GitOps.

RabbitMQ

Similarly by utilizing RabbitMQ's Cluster operator and
Messaging Topology operator we're able to avoid the
need for the rabbit-init job by utilizing the correct
operator resources.

apiVersion: rabbitmq.com/v1beta1
kind: Vhost
---
apiVersion: rabbitmq.com/v1beta1
kind: Queue
---
apiVersion: rabbitmq.com/v1beta1
kind: User
---
apiVersion: rabbitmq.com/v1beta1
kind: Permission

The above resources, when configured do the following:

  • create a vhost
  • create a queue in the vhost
  • create a user
  • grant permissions to a user on the queue in the vhost

Which is exactly what the rabbit-init script does when executed
as a job. Lastly as these scripts aren't used the associated
RABBITMQ_CONNECTION secret value isn't necessary allowing us to disable the
secret_rabbitmq manifest.