spicedb migrations are intended to be
# spicedb
y
spicedb migrations are intended to be backwards-compatible, right? like i should be able to run the migrations for a new spicedb version against a cluster running my old spicedb version without breaking anything?
v
actually no, some migrations are not backward compatible, and there is no testing in place to make sure it is backward compatible
y
🤔
is that a part of why the operator is recommended?
it'll walk as needed?
i just broke our testing env because we run our deploy of a new version of spicedb right before running the associated migrations, but our migration step broke 😛
v
yeah this is all coded into the operator, but not because of backward compatibility
y
gotcha
bleh
hopefully we get onto k8s soon -_-
v
it's there just to orchestrate multi.phase migrations
and if you migrate the database, and run an older spicedb, spicedb won't come up healthy
because each version expects a specific datastore schema version
y
hmm... interesting
so the operator also takes care of failed deploys and rolling them back as necessary?
j
it won't rollout if the migration fails
it keeps the existing cluster running
y
right - i'm thinking of the case where the migration runs but the deploy doesn't for whatever reason
like does the operator run
migrate <tag>
for the specific migration associated with the version?
j
it uses the version container
and runs 4 phase migrations if need be
I think your question is: how does this not break the existing running cluster?
the answer is: if a migration can break the cluster, its run 4 phase
with each phase being immediately back compat with the previous phase
but only immediately back compat
and the operator will handle each phase
3 Views