In thinking about this a little more, I think this proposal is actually a subset of your proposal #259 above. As far as I can tell, if the initial bootstrap file used in

zed import

doesn't contain a

relationships:

block, then no relationships are written or deleted. Also, if there are relationships that already exist, it's a no-op. So I think I could work with that file format as a configmap. FWIW, our use case is basically the following scenarios, and I'm hoping spicedb-operator can eventually handle all of them. We have a single-tenant architecture, so we are supporting a fair number of independent SpiceDB clusters that we want to update together: 1. For new SpiceDB clusters, we want to write an initial schema and set of relationships once the cluster is migrated to our desired version. 2. For outdated SpiceDB clusters, we want to be able to update the cluster. I'm worried that a schema we'd want to apply depends on the SpiceDB upgrade/migration happening first (e.g. caveats), so I'd love for the operator to "bootstrap" the upgraded cluster with the new schema but not overwrite the relationships. 3. For steady-state SpiceDB clusters, we want to be able to push a schema update across all clusters. A

zed schema write

or a

zed import

with an empty relationships block (or one containing just the initial bootstrapped relationships) would do it as long as it's not destructive to the rest of the relationships we've added over time. I'm pretty agnostic as to whether the operator actively manages the schema via only the ConfigMap and locks down the WriteRelationships API in SpiceDB -- that may be the cleanest solution though.

I had also thought about extending the operator to run an arbitrary k8s job as a post-migration hook, but I think the plumbing to make that work--figuring out the SpiceDB cluster endpoint, injecting a secret, handling job errors, etc.--is probably more effort than it's worth.