@snax the "Hosted" service, correct?

yup

no plans at the moment for any major price changes to it

Thanks!

Hey, Can YugabyteDB be used as a datastore for spicedb?

there has been an issue filed, but no implementation as of yet

Thanks I didn't see that

definition post_prasenjit_tutorial/user {} definition post_prasenjit_tutorial/group { relation member: post_prasenjit_tutorial/user relation admin: post_prasenjit_tutorial/user relation parent: post_prasenjit_tutorial/group permission edit = admin + parent->edit permission update = edit permission delete = edit permission read = member + edit permission has_access = member + edit + parent->has_access } definition post_prasenjit_tutorial/platform_permissions { relation template_update_group: post_prasenjit_tutorial/group relation template_view_group: post_prasenjit_tutorial/group permission template_update = template_update_group->has_access permission template_view = template_view_group->has_access } definition post_prasenjit_tutorial/template { relation permission_relation: post_prasenjit_tutorial/platform_permissions relation group: post_prasenjit_tutorial/group permission update = (permission_relation->template_update & group->has_access) permission view = (permission_relation->template_view & group->has_access) }

* I am trying to optimise for schema change here. I understand resource can't be user defined , so creating of new resource or adding permission to the resource will contribute to schema change. * I am adding permission to a group dynamically. inspired by this : https://authzed.com/blog/user-defined-roles/ * I am not able to contextualize the permission given to a user in a group. As in this example sumit should not have view permission on xyz template because xyz is not part of the group which has view permission. Is this possible to achieve when permission is dynamically added to a group? // // post_prasenjit_tutorial/group:vcs#member@post_prasenjit_tutorial/user:tanu // // post_prasenjit_tutorial/platform_permissions:mcp#template_update_group@post_prasenjit_tutorial/group:vcs // // post_prasenjit_tutorial/template:xyz#group@post_prasenjit_tutorial/group:vcs // // post_prasenjit_tutorial/template:xyz#permission_relation@post_prasenjit_tutorial/platform_permissions:mcp // // post_prasenjit_tutorial/group:wmd#member@post_prasenjit_tutorial/user:sumit // // post_prasenjit_tutorial/platform_permissions:mcp#template_view_group@post_prasenjit_tutorial/group:wmd // // post_prasenjit_tutorial/group:vcs#member@post_prasenjit_tutorial/user:sumit assertTrue: - "post_prasenjit_tutorial/template:xyz#update@post_prasenjit_tutorial/user:tanu" - "post_prasenjit_tutorial/template:xyz#update@post_prasenjit_tutorial/user:sumit" - "post_prasenjit_tutorial/template:xyz#view@post_prasenjit_tutorial/user:sumit"

Hi, Each call of the writeSchema(request) method creates a new namespace in Postrges. Is there a way to write schema without creating new namespaces?

Hi All! Recently been trying to get an instance of spicedb running on cloud run with a connection to cloudsql(postgres), it seems to connect to the db fine, but I'm running into issues whereby a signal is sent prompting the "received interrupt" log to be returned (which is found in the SignalContextWithGracePeriod function). When I run my instance locally and connect to cloudsql through the proxy, this does not occur, the instance is able to serve and take requests. I'm wondering if anyone has tried a similar path or encountered a similar problem? Any assistance is appreciated.

👋🏻 howdy! as far as I can tell the

spicedb serve

command is wired up with

SignalContextWithGracePeriod

which handles terminating the process on

SIGINT

and

SIGTERM

. Assuming you are running it in a Kubernetes cluster, have you checked if your pods are being terminated / rescheduled (e.g. resource limits)?

a "namespace" is the name we use in the database for each

definition

in the schema - when you write a schema you create many namespaces, so this is expected is there something you're trying to do with writeschema that isn't working the way you expect?

I have never personally used cloud run, but I'm guessing that you're hitting their "scale to zero" feature and the process is being terminated when no traffic is coming through. have you tried setting min instances? https://cloud.google.com/run/docs/configuring/min-instances

We want to write schema each time we start the app. It creates new schemas even though nothing has changed. Over time, the database will be full of unnecessary duplicates. Couldn't this perhaps affect performance in the future?

The postgres driver implements its own MVCC, so each of those is a record of what the the namespaces where at a specific snapshot in time. (if you check the created_transaction and deleted_transaction columns you should see those values changing) There's a GC process that cleans them up as they expire, so there's no risk of it filling up It could make sense not to generate a new revision on write if the data hasn't changed, but that might just be more effort than it's worth

Ok, thank you for the clarification. And yes, maybe we will try to write only changes.

Hello! My ops team is reaching out to me with a question about SpiceDB, rather than paraphrasing I'll just copy-paste it here: > I’m looking at what we’re missing to upgrade our Kubernetes clusters to 1.21. The only change that could affect us (at least from my research) is that Service Account tokens now expire and are rotated. > As a refresher, Service Accounts are Kubernetes’s equivalent to an AWS IAM Role, it’s an identity for a machine. Service Accounts are linked to Pods, and Kubernetes generates a token to authenticate the SA, and injects this token into the pods in a well-known path. > Starting with 1.21, these tokens expire and are rotated on disk automatically. Official SDKs already support reading the token from disk when it expires. > However we have an issue for SpiceDB: it uses the Kubernetes API to discover sibling instances of SpiceDB (for dispatch IIRC), based on kuberesolver . However kuberesolver doesn’t use the official Go Kubernetes SDK, it implements its own lightweight client, initialized here https://github.com/sercand/kuberesolver/blob/master/kubernetes.go#L59-L86. I couldn’t find it its source code any reference to refreshing that token. > The default expiration period for these tokens is 90d in 1.21, but it will be reduced to minutes our hours in following updates. > This means that if a SpiceDB pod is alive for more than 90d (and much less later), it won’t be able to refresh its list of siblings for dispatch. Is this something you're aware of, is it correct, is there plans to address it?

Thanks for the heads up @williamdclt - aware of token rotation in general but I forgot that kuberesolver implements its own client. We can issue a patch upstream (or fork if it comes to it)

I think this is going to be an ongoing risk with

kuberesolver

since it by design wants to "avoid the bloat of the Go Kubernetes SDK".

Hi, can you please give me an example for deleting all the relationships in the spicedb using

DeleteRelationships

? Like clearing whole db for testing purposes.

Hi, does anybody know if it is possible to run

migrate head

and

serve

in the same docker container?

If this is for unit-testing, you should look at the

serve-testing

sub-command which uses a separate datastore per access token. Otherwise you have to iterate the object types and call delete relationships on each one.

You can use the same container image, or you can do it by

exec

-ing into the container, but that’s not recommended. You could also inject your own script to do so into a new container image. What’s the use case?

Can we use Authzed java/ nodejs client for SpiceDB as well ?

Using docker compose I now state to use two containers of the same image one

migrate head

and one

serve

. But then after up there is one exited container (correctly) laying around so I wondered if I could just use that container for

serve

again

Does it work with SpiceDB as well or is it only for enterprise version authzed?

Oki thanks

All of our client libraries will work with SpiceDB. Their names predate the naming and open sourcing of SpiceDB.