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.