contributions are also welcome 🙂

that seems fair, I will create a PR adding the examples I use in my POC at my work 🤝

This is for a feature branch in staging

@here We just created an Awesome SpiceDB list! Check it out, you might find a useful resource for SpiceDB that you never knew existed! If we're missing something, you can also add resources that we never knew existed by opening a pull request, haha https://github.com/authzed/awesome-spicedb

i'm working on getting opentelemetry stuff set up. I've added a

SPICEDB_OTEL_ENDPOINT=localhost:4317

and a

SPICEDB_OTEL_PROVIDER=otlphttp

environment variable, but it looks like it's trying to hit the sidecar with https, which doesn't work because it's expecting http. what's an example value for

ENDPOINT

? is it a full url? (e.g.

http://localhost:4317

?)

I think you have to use the standard OTEL environment variable to enable insecure. I'm not 100% sure about this though

where would i find that?

SpiceDB's CLI should uses the Go OTEL SDK to read these values -- if it doesn't, I'd file an issue because that's a bug either on our side or in the OTEL SDK

looks like you can provide a scheme in the endpoint (http or https) and it will respect that (looking here: https://opentelemetry.io/docs/reference/specification/protocol/exporter/#configuration-options). thanks for pointing me in the right direction!

wait, would those environment variables also be prefixed by

SPICEDB_

?

yes

if being passed as an env var

to SpiceDB itself, that is (edit: but apparently not for OTEL: see @jzelinskie's response below)

yeah that's what i'm not clear on. what's the relationship between the OTEL code that's consuming these variables and spicedb?

is spicedb still the entrypoint and so it's going to look for all

SPICEDB_*

env vars and then pass those to all downstream code which will include the otel exporter?

i'm still seeing log messages like it's trying to use HTTPS with

SPICEDB_OTEL_EXPORTER_OTLP_INSECURE=true

in the environment

Hey guys! I have a small question when writing relationship. I'm using the python client. Is there a way to check if a relatonship exists before writing it? Or some way to "skip" writing an existing relationship? If not, what would be the appropriate way to catch the exception that is raised when a relation already exists? Thanks a lot!

@pablo.estrada both. you can either write a relationship with a precondition that it doesn't exist (or another relationship does, or doesn't, etc). You can ALSO have the relationship write use the

TOUCH

operation, which, if the relationship doesn't exist, will (more or less) no-op

CREATE

, on the other hand, will raise an error if the relationship already exists and you try to write it

Super that help me a lot thanks Joey!

I recommend using

TOUCH

if you don't mind if the relationship already exists for the write to be "skipped"

I believe so, yes (edit: apologies, see @jzelinskie's response below)

For standard OTEL variables you don't use the SPICEDB prefix -- we only use that prefix on CLI flags

Hi, I have a problem on my local environment. SpiceDB is in the Docker with datastore in Postgress. It takes almost 5 seconds to write and check the relations. Is it possible to write it faster? Or is there any way to know when it's written down? My test in Java Using this

PermissionsServiceGrpc.PermissionsServiceBlockingStub

permissionsService

When I write any relationship

permissionsService.writeRelationships(request);

and I'll run a check right away.

permissionsService.checkPermission(request);

It returns

PERMISSIONSHIP_NO_PERMISSION

But if I wait about 5 seconds and call it again

permissionsService.checkPermission(request);

It returns the correct answer

PERMISSIONSHIP_HAS_PERMISSION

@Jaroslav Holaň SpiceDB uses an in-memory cache, which is renewed every 5s (see

--datastore-revision-quantization-interval

). It makes SpiceDB eventually consistent by default. You can specify the level of consistency when making a check request, it sounds like you want

fullyConsistent

here. It makes the check much slower, but you probably don't care in tests

Good point. Thank you. I found the doc https://docs.authzed.com/reference/api-consistency

and to make sure i'm following - these are SpiceDB variables and need the prefix:

--otel-endpoint string           OpenTelemetry collector endpoint - the endpoint can also be set by using enviroment variables
      --otel-provider string           OpenTelemetry provider for tracing ("none", "jaeger, otlphttp", "otlpgrpc") (default "none")
      --otel-service-name string       service name for trace data (default "spicedb")
      --otel-trace-propagator string   OpenTelemetry trace propagation format ("b3", "w3c", "ottrace"). Add multiple propagators separated by comma. (default "w3c")

where the other OTEL configuration env vars do not use the prefix?

^ the above being from

spicedb serve help

Yep! We read the other environment variables using the OTEL SDK and not our flag library.