does that make sense? if so I think we can write up a couple of gh issues to track

Thanks for the feedback! Let me follow up tomorrow @User , It's getting late here! Thanks a ton! ♥️

I need to re-read, but I think the Zanzibar paper also says that Google tried hedging dispatches and decided against it as it didn't improve anything and caused lots of additional load.

Hello guys, At what condition will Permissionship.Unspecified be returned when checking for a permission ?

@User right now, only if an error occurs

which practically means if you're catching or checking for an error (depending on language of the client), you should not encounter it

we do, however, always recommend comparing to

HAS_PERMISSION

to allow access

Permissionship.Unspecified is the zero-value in protobuf, so we intentionally surface it as that so it can be distinct from not actually having permission.

got it, thank you guys

>I think that if we make the node unavailable until it gets an initial dispatch peer list + some metrics you could alert on if dispatch isn't able to refresh the peer list for some period of time would fix the issue? @User following up on yesterday's conversation: I thought about the exact same thing! 🎉 Given how important internal dispatch is for the latency goals, it would make sense to surface problems there as early as possible. A challenge is that pods wouldn't be able to become healthy, leading to potential cascading failures if Kube API is having trouble, so one possible option is to check if SD is healthy on bootstrap, and if it's not, fallback to starting with local dispatch. I think some metrics around SD and comms with Kube API would help. Kube operators are generally wary of anything that puts load ok the Kube Server API, so it would be useful to know things like request count and latencies when talking to kube API. Generally on board with what you shared!

Great! I'll get these written up for github

Has anyone used spicedb/authzed for feature flagging?

@User we do

there are a few nice ways to do so: you could use a specialized permission on a flag itself, for global flagging

or you could have a special permission per feature, and grant access to specific users or users in general

global flag example:

definition featureflag {}

definition platform {
  relation enabledflag: featureflag  
}

then your check could be

platform:platformname#enabledflag@featureflag:somefeature

per feature flag:

definition user {}

definition platform {
  relation feature_somecoolfeature: user | user:*
}

and then your check could be

platform:platformname#feature_somecoolfeature@user:currentuser

. The benefit of this design is you can grant specific features to specific users, or to

user:*

to enable it for everyone. you also can in theory pull the feature flag permission into other permissions, so you could do something like enable new permissions based on a feature being turned on (or turned off) for a specific user

👋🏻 hey friends, working here on the internal dispatch in our deployment. I managed to go past the

403

. from kuberesolver, but getting

Error: rpc error: code = Unavailable desc = last connection error: failed to receive server preface within timeout

Im going to do some further investigation, but something that stood out to me is that the log messages are sending mixed signal around the gRPC status code. Was suprised to find

ok

, and it turns out that the

started call

has a

grpc.code

tag, when it shouldn't (because the call is just starting!).

4:55PM INF started call grpc.code=OK grpc.component=server

Would it make sense to drop the

grpc.code

. from that message, to help us filter by actual status code when the response returns?

Another thing that could help would be to record an error in the OTel span, so that it can be visualized in your Tracing UI of choice

@User what API call are you making?

I'm doing a normal Check

(PermissionCheck i mean)

@User we should probably move this discussion to #900405749405089812

I'm still terrible at this, sorry 😭

Just stumbled upon the SpiceDB talk at CMU on YouTube. Fantastic presentation Jake! 👏

Quick question, any good guidance of the infrastructure requirements for spicedb? Like cpu / ram number of nodes ...

I was actually just trying to scope that out for our enterprise documentation -- which is publicly available information.

There really is no hard and fast rule, so long as you aren't running out of memory that SpiceDB is using as cache. I'd personally recommend starting with a minimum of 2 vCPU and 2GiB of RAM allocated for an instance of SpiceDB and scaling up from there. Because SpiceDB is a latency focused application, aspects like having faster cores or being the only software running in a particular machine are going to come into effect more quickly than you'd think and can be more beneficial than adding more cores/ram.

Thanks @User for the info. As I understand SpiceDB it is best to give SpiceDB as much memory as one can to maximize cache hit. I assume that if the result does not fit in memory the older caches will be invalidated. And SpiceDB will not go into OOM. Is my understanding correct? Thanks again.

@User SpiceDB caches are currently capped in code to a specific memory footprint. We're investigating making that configurable