Nope, there really isn't anything to it. SpiceDB accepts all of the standard OpenTelemetry environment variables and you just configure them for Jaeger, as per the Jaeger or OpenTelemetry documentation

if you'd like you can do jaeger protocol directly (old versions of jaeger don't support otel protocols) by providing

spicedb serve --otel-provider jaeger

Otherwise you just need to do

spicedb serve --otel-provider otlpgrpc

and the rest can be configured with

OPEN_TELEMETRY

environment variables

Thanks @jzelinskie @Joey

Schema Texts aren't proper JSON, are they ?

the overall request is JSON

I get your point, value is string and it could be anything, adding new line characters in that string is very cumbersome, I was looking for easier way if possible.

and since the whole request is JSON, you should just be able to encode it as a JSON object

Yeah, that works fine, I am using postman to send schema Text , there I have to do a lot of /n , and I am but lazy 😀

Hi, it's me again

I got spicedb working and now I'm trying to create a pipeline that uses zed to define the schema

the pipeline runs on a container

the problem is that zed has keyring integration

is it possible to disable it?

(keyring is not available in the container)

@jzelinskie ^

alternatively, how can we do validations with http api and curl? it seems this api is not feature parity with zed command

you can skip the keyring by providing the token and endpoint as flags instead

hmmmmMMMMmmmMMmmMmMmMMmmmM

interesting

testing nowwww

Hello, I have a question about health-checks and

grpc-health-probe

. Understand that

grpc-health-probe

can be used [for Kubernetes] to report on health of gRPC services. I would like to try running SpiceDB on a managed container service, for example

ECS Fargate

. Should I enable HTTP gateway and use that for health probes, or is there a way to use

grpc-health-probe

or something else under AWS Fargate to conduct health checks, without HTTP Gateway enabled?

Hello! We've also encountered the k8s token refresh problem while building a POC with SpiceDB. Already on 1.21 and planning to upgrade to 1.23 soon, where it becomes a blocker. I saw that someone submitted a patch to kuberesolver, but it's unreleased yet (and apparently buggy). Just wondering if you have any plans to tackle this?

We will definitely make sure that there is a reasonable way to run on kubernetes; we may need to contribute fixes to kuberesolver. It seems like kuberesolver has some principled stance against using official go kubernetes libraries in their implementation - at least, it's not obvious why they wouldn't use them otherwise. We already have our own grpc load balancer implementation, it may make sense to have our own resolver implementation that uses

client-go

as well (

client-go

properly handles token rotation, as you might expect). I don't have a hard timeline for you but this is something that will get addressed, probably sooner rather than later.

does Fargate support gRPC in any form?

@Joey gRPC uses HTTP as the transport protocol, i believe. Fargate is a managed/serverless container service offered by Amazon. a typical setup has a load-balancer connecting fargate tasks to a public network, and possibly a private subnet, some pods/containers, health check endpoints, along with tresholds, etc. happy to share what i know about AWS. maybe in a direct chat, it would make more sense.

it does, but it has a particular envelope format

my guess is that unless Fargate explicitly does support gRPC, you'll need to use standard http

just found something. it seems that AWS integrated gRPC support into the ALB. https://aws.amazon.com/blogs/aws/new-application-load-balancer-support-for-end-to-end-http-2-and-grpc/