Quick question around the SpiceDB Operator: is there a way to get new versions of SpiceDB when using the operator without having to update the operator itself? I tried using channel

stable

and version

v1.30.0

earlier on with the latest operator (

v1.13.0

) but it was giving me a

no update found in channel

error and I had to go back to

v1.29.5

.

you can pin directly to the spicedb image, but the operator will miss the update graph. Are you using postgres? because there is a phased migration in 1.30 you should be aware of

Using Postgres pinning the image, but pinning to

v1.30.0

didn't work

did you use

spiceDBImage

field?

The operator (currently!) only has a

stable

channel, which means we don't put new releases in it right away you can set

.spec.config.image

to an image if you want to override it to point to the newest release, but you'll miss out on phased migrations if there are any

We pin versions with in the channel, so I'd love to have a channel that always had all releases in it. We've had to use the

.spec.config.image

workaround a few times, but then we lose the best feature of the operator.

Is there a versioning issue then if releasing

v1.30.0

doesn’t mean it’s considered stable yet? Should it be tagged as

v1.30.0-rc1

or something? It also seems inconsistent with the fact that the

zed

CLI tool immediately started giving me warnings at every command that I’m not using the latest server.

Right now we consider stable versions 1 version behind the latest release. We consider it stable when it has passed our internal QA.

It’d be useful if there was easily the option to update to the latest server via the Operator, but because right now that’s not the case then it’s mostly noise IMO. I still find it confusing that releases are being tagged that aren’t officially being considered “stable” and that haven’t passed QA. Surely those would be release candidates and you would only tag the actual release once it has passed QA and is deemed stable?

As mentioned earlier, we tag them when they pass our own internal QA. There is room for improvement there for sure, we don't catch all types of issues. For that reason we consider the latest version not necessarily the most stable.

First - we 100% plan to add a channel that gets updated with every spicedb release, we just need to find the time to build the automation for it. So that is coming, and you'll be able to just subscribe to that and that should fix the immediate concern. Also totally agree that

stable

is a misleading name. We also use an update graph to deliver spicedb-enterprise to the SpiceDB Dedicated clusters that we run, and we opted to call those

rapid

and

regular

to better reflect the distinction. It's really that the

stable

/

regular

channel receives releases less frequently, which limits the number of times your infrastructure can change (less frequent changes = more error budget for SREs). It's really not about the "quality" at all, we have extensive automated tests and we run release candidates in production environments before we tag a SpiceDB release. I think likely when we add the

rapid

channel to the spicedb-operator, we'll add an alias to the

stable

channel to rename it

regular

so that it's less confusing

Thanks for the explanation. And to clarify something that was mentioned earlier in the thread, is the update graph is bundled within the operator and therefore if I want to have access to the latest SpiceDB version within my channel I'd have to update the operator? Or does the operator fetch new update graphs as they come out and I therefore can update SpiceDB without having to update the operator every time?

you need to update the operator