Hey 👋 we kinda missed the latest
# spicedb
d
Hey 👋 we .. kinda missed the latest spiceDB updates, so a maybe silly question: Is it ok/safe to update from 1.20.0 to 1.22.2 directly, or should we do an intermediate update first?
I guess
Copy code
We highly recommend updating sequentially through SpiceDB minor versions (e.g. 1.0.0 -> 1.1.0) to avoid headaches. Jumping many versions at once might cause you to miss instructions for a particular release that could lead to downtime
is what we should do (from the docs). So 1.20.0 -> 1.21.0 -> 1.22.0 -> 1.22.2
v
right, this is what the operator handles automatically for you. It has an update graph baked into it, and knows the sequence of steps versions and migrations to run. It'd be advisable to check the release notes of each version to understand if there are migrations involved, if there are multi-phase migrations involved, or if there are breaking changes to the dispatch API which would make it incompatible to cluster together pods from different versions.
d
Thanks for the answer. Currently it'd be no problem to have a downtime, and yes, the operator would be awesome, and I'll poke internal constraints again for that one 🙂
safest is update to 1.21.0, then to 1.22.2 I guess, with downtime, right?
(I'd avoid 1.22.0 bc of the warning in the release notes)
v
what database are you running?
the only migration that I'm aware of is Spanner in 1.22.0
and yes, 1.21 -> 1.22.2 is the recommended route. It will cause some errors as dispatch APIs are incompatible, but should recover by itself
d
postgres
so we don't need to use the migrate head command then, right?
v
yeah, according to the update graph there are no migrations involved for PG: https://github.com/authzed/spicedb-operator/blob/main/validated-update-graph.yaml#L169-L177
and you could also technically move directly to 1.22.2
I think 1.20 was removed from the graph as it had some perf regression, if I'm not mistaken. @ecordell?
e
yeah, 1.20 just wasn't added to the graph. no point in running it once 1.21 became available. looks like we're all set now though!
d
@ecordell we are all set, ty! 🙂 Out of curiosity, as I didn't monitor the developments lately: The spiceDB operator is not currently available to use namespace scoped, right? We have some constraints on a multi-tenant platform to deploy it cluster scoped(permissions, security issues like access to secrets, ...) and being able to run it ns-scoped would be great.
2 Views