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.