it would be great to close the loop on your requirements and get them in our schema language as first-class options

when we have more idea of the intent behind things, it opens up options for more interesting optimizations

Considering the already existing offerings, everyone is familiar with the

platform.service.action.*

permission logic, which is what we are attempting to implement within SpiceDB

that's just one model that you're focused on though, IaaS, we have SpiceDB users modeling all kinds of interesting domains and non-RBAC-y permissions systems

That's for sure, but RBAC-y style is the one expected and used by most larger scale operations, as that gives you much more abstract level of control. But implementing it in SpiceDB feels like an unintended exploit.

Hi everyone, we put together a short survey to help the SpiceDB maintainer team hear about your experience setting up and using SpiceDB: https://forms.gle/t1X7qFnx9Z6oKvk89 It’ll take a few minutes and will be invaluable to us as we look to make SpiceDB better and easier to use. Any and all feedback is welcome and much appreciated!

After a lot of testing I have a gut feeling like there's some bugginess related to using the following type of indirection:

relation a: a
permission b = a->b
permission c = b

Sometimes I'll get false negatives on the

c

permission. When I do

zed permission expand

, c will expand to b and then a->b but won't pick up any of the subjects in a->b. But when I expand

a->b

directly those subjects are there. It seems to be intermittent and inconsistent, and when it does happen, a restart of spicedb or a rewrite of the zedfile seems to clear up the issue.

I can try and come up with a concrete example in the morning but it won't be reproducible.

I define the inderection like this:

relation b: a#b
permission c = b

I see the behavior if

a#b

is a permission but not if

a#b

is a relation.

My gRPC calls use the

FULLY_CONSISTENT

option.

Anyway, heading to bed, it's 10pm my time. I'll be on in the AM to get some help, just wanted to let this marinate.

I'm having a hard time understanding your scenario. Is it the top example that's causing problems or the bottom? And you're saying you see an issue when the

b

in

a#b

is a permission but not if the

b

is a relation? It would be helpful to have a full schema example of both the working case and the case that's causing trouble.

I'm observing enormous usage of memory in production :/ SpiceDB instances are using >10GB of RAM and getting OOMKilled, so availability is very very low. Is it expected that SpiceDB is that memory-hungry (using v1.5.0)?

Is there any setup I need to do for this to work? I have

spicedb

helm chart running and its pointing to my Postgres DB, but the postgres database has no tables

You need to first run

spicedb migrate

with the same config env/flags. The helm chart is a community contribution and we don’t use it internally.

Ah, ok that makes sense. Do i need a blank (empty) db with the name, or does it create that for me?

There is a pprof endpoint on the Prometheus server port which should allow you to get a heap dump. Can you inspect that or send it to us for inspection?

I’m not 100% sure of the url but it should be something like: localhost:9090/debug/pprof

You need a blank db with the name, the db uri must also be configured with that name

ok great, thanks

is the migrate command something to only ever run once, or should i run it on all deployments of spicedb to keep it up to date?

You can always run it, it will no-op if nothing needs to be done. You will need to take care to only run one at a time.

Like with a k8s job

Okay cool

@User What do I use for the value of

revision

?

You can use

head

Great, thanks

I'll do that!

Yeah, trying to come up with a reduced set of data that triggers it.

@User FYI, we define a post-upgrade hook to run migrations: