I'm unfamiliar with the k8s parts of that stack, I...
# help
a
I'm unfamiliar with the k8s parts of that stack, I'll ask around tomorrow. Is there a description somewhere if the steps fluxcd takes when deploying a new version? I'd like to stick something on before it starts the new version, obviously.
t
fluxcd basically has a CR in k8s
HelmRelease
it does a rolling update
so tries to spin up new pods for new lakefs version
before shutting down older version pods
we face similar migration issues many times earlier (with other apps)
lakefs container needs to auto run the migration on detecting older schema version in DB
otherwise the new pod will always fail and new version deployment of lakefs will fail
hope this helps
a
OK, thanks! I figured as much. We could probably add a flag to migrate on startup. IIUC that would work for you. But note that I think rollback might not always be possible without losing some metadata. (I would not want this behaviour always - in less CD deployments there is greater risk, e.g. if one runs a wrong version in error.)
I'll set if I can get you a PR to do that tomorrow.
Actually, it's possible in one direction (upgrade) but not in the other (downgrade). You'd need an explicit step using the up to date version (which knows what to remove to change back) being told what the less recent version that is being installed needs. So I'll do it, but it's always going to be a ratchet - you can go up but not down like this.
t
understood
y
Hey @T. P., published a new version (0.4.7) of the Helm chart, which runs the migrations automatically on upgrade. Let me know how it works
t
great, will test out today and provide feedback, thanks
👍🏻 2