So what is the contract that we have to obey in order to make sure it functions as expected?

that all SpiceDB nodes are within that DNS address

and ideally, removed from it when they go out of service

but: be aware that DNS update-based is slower than k8s service based

which means there is a small, but real, chance you might try to dispatch to a node that has already left service

which is why DNS-based isn't as recommended

The kuberesolver is faster because it receives events when a pod goes down? So in the event there was a stale spicedb server in HAproxy the service will timeout, or just not get a cache hit? We will just suffer from long requests?

Looking at Kuberesolver, it doesn't look complicated to implement a resolver plugin if DNS will be too painful

yeah, if you can do so, this is ideal

you'll want it to update as soon as the node is out of service or another comes into service

yea, I don't know k8s, but it looks like that resolver looks at the api/v1/watch

which looks like it just handles events for state change on a particular k8s resource

What happens with DNS if there is a stale spicedb tho, just curious how it handles if a node goes down etc

if the node is still in DNS, then we'll try to dispatch to it

which could result in an error

question around the otel integration in spicedb - I was trying to link the traceids from my application to spicedb using the propagators as per https://github.com/authzed/spicedb/blob/a891b7ffd7c1d829c10b5616fac792dbc88f3a33/internal/gateway/gateway.go#L133 the default global

TextMapPropagator

is used, but according to this https://pkg.go.dev/go.opentelemetry.io/otel#GetTextMapPropagator - if none is explicitly set, it defaults to a 'no-op' propagator does this mean that there is no propagator integrated into spicedb right now? I found https://github.com/authzed/spicedb/blob/a891b7ffd7c1d829c10b5616fac792dbc88f3a33/internal/gateway/gateway_test.go#L18 the TraceContext propagator being used in the tests

@smithp4ntz I know that our team mate Evan worked on introducing support for XSD-based dispatching: https://github.com/authzed/spicedb/pull/612 I know that some folks have used it for non-k8s envs

@Perseus 👋🏻 OTel tracing should work with the gRPC server, as we integrate the gRPC OTel middleware. I'm not so sure about the REST Gateway tho

Perseus0161 👋🏻 OTel tracing should

@vroldanbet Thanks for the information. this leads me to have to go learn about xDS lol

Holy shit its a lot

i noticed in some videos on youtube that you've created some patterns, is there a place where I can learn those best practices / patterns / idioms of spicedb schema creation?

its spread over different sources but https://authzed.com/blog/schema-language-patterns/ for some common ones

we also have https://authzed.com/blog/user-defined-roles/ for user defined role patterns

@Joey Thanks so much

We currently authenticate a user and they receive a jwt token. The claim has a "permissions: [ $namespace:$role ] " which is populated by whatever group memberships you are in. WIth SpiceDB our app / operator would use WriteRelationships() to create groups and put users into groups and in our app only need to pass the User to CheckPermission to authorize or not ? Trying to make sure I understand that instead of putting folks into Groups in our Authentication system, we'd do that in Spice. The only thing needed then in CheckPermission would be the users identity, not their groups / roles or anything from outside system?

We currently authenticate a user and

How can we have dynamic relationships, for example in Schema we define manager, owner these pre-defined relationships to set relationship between resource and object, what about scenarios when relationship are also dynamic?

I looked at this, but even in this example relations are always predefined, like issue_creator etc.