K8s: Disabling `RUN_MYSQL` should also not deploy the mysql init job

[waza-ari]

Bug description

When trying to run tutor with an external MYSQL database, we're setting RUN_MYSQL to false which prevents the pod to be created. It does however still create the MySQL init job, which is doing nothing else than creating the database for openedx.

We'd prefer not to specify root credentials here, but instead specify credentials directly using:

tutor config save --set RUN_MYSQL=false
tutor config save --set MYSQL_HOST=mysql.database.svc.cluster.local
tutor config save --set OPENEDX_MYSQL_DATABASE=openedx_dev_dev
tutor config save --set OPENEDX_MYSQL_USERNAME=openedx_dev_dev
tutor config save --set OPENEDX_MYSQL_PASSWORD=XXX

Use case would be a centrally operated database, in our environment using a database operator within k8s.

How to reproduce When trying to bring up the platform, it will fail with the following error message:

kubectl apply --kustomize /Users/dherrman/Coding/ArgoProjects/openedx-dev/tutor/env --selector app.kubernetes.io/name=mysql-job-20240317133311
job.batch/mysql-job-20240317133311 created
Job mysql-job-20240317133311 is running. To view the logs from this job, run:

    kubectl logs --namespace=openedx-dev --follow $(kubectl get --namespace=openedx-dev pods --selector=job-name=mysql-job-20240317133311 -o=jsonpath="{.items[0].metadata.name}")

Waiting for job completion...
Error: Job mysql-job-20240317133311 failed. View the job logs to debug this issue.

Either RUN_MYSQL should also prevent the job from being created, or we may want to introduce another variable to achieve that.

Environment Mac OS Sonoma 14.2.1 Tutor version tutor, version 17.0.2

[regisb]

Ditching the mysql init job entirely seems rather drastic, so I'm not sure that's the actual solution to your problem. Can you please provide us with the logs from the mysql init job to understand why it's failing? (be careful not to share production credentials from these logs)

[DawoudSheraz]

@waza-ari Hi, just trying to catchup and see if you can provide the answer/context to what Régis asked above. Thanks

[waza-ari]

My apologies, I got hung up on different topics and in the meantime am hosting our dev environment on a regular Ubuntu machine instead of K8s, to stay closer to the production environment.

If I remember correctly, it was about the job assuming root privileges when trying to create the openedx database instead of using the provided one. Especially in shared environment, root privileges should not be assumed imho. As I currently don't have a setup to test it with and as apparently no-one else complained about this, I suggest closing it for now unless you want to look at it anyway.

[regisb]

Indeed, none of the k8s jobs have a securityContext, like the deployments do. I think this should be flagged as a bug.