Clarification on automigrate option within k8s helm chart

ORY Hydra
#1

Hi,
one ambiguity arose on automigrate option while trying to put hydra helm chart to life into some production grade k8s (meaning more than 1 pod replicas) . According to hydra docs (the part where releases specifically instruct running migrate on db initialize or upgrade). I assume migrate is not idempotent operation and as such I see not safe to put into initContainer.

Or am I wrong and operation is safe to run on every redeploy(i.e. at hydra upgrades) and all replicas in k8s cluster? Seems initContainer logs suggest this - observed at hands on test - i.e. redeploy to same hydra version gives information on 0 changes to be performed in db and initContainer exits successfully:
The following migration is planned:
| DRIVER | MODULE | ID | # | QUERY |
|--------|--------|----|—|----------------------|
|--------|--------|----|—|----------------------|
Successfully applied 0 SQL migrations!

Or it is expected to toggle option enabled manually only at explicit systemOps intention as release instructs?

Or even more conservative - doing migrate only from some ‘outside k8s’ hydra instance and also not ‘live’?

If this last is true, what about using helm hooks (pre-install, pre-upgrade) and run migrate as a job?

Thanks in advance and kind regards

#2

It is safe to run migrate more than once on the same DB snapshot. I’m not 100% sure if there could be an issue where to migrate commands run concurrently and both try to migrate the DB - this might cause some issues.

In general all of that really depends on your environment. Of course, manual “outside-of-cluster” upgrades are probably ops best practice because it allows you to do backups before and remedy any issues right away (because of the manual step). A manual step does not necessarily have to run on a dev machine, it could also be in the CI with some manual job approval of some sort.

So it’s really up to you and your requirements.