I think you could use a wildcard for "type 1" users to make them all reachable for the resource... but I'm unsure from your description how type1 users are reachable from type2 users. Can you expand a bit?

the bearer token is how to call the API; the permission is defined in your schema

this is what i meant with - has somebody an example. I don't know how the schema has to look like for the particular example here: prom-authzed-proxy \ --proxy-upstream-prometheus-addr http://localhost:9090 \ --proxy-spicedb-token tc_client_token_1234deadbeef \ --proxy-check-resource-type metric \ --proxy-check-resource-id-query-param install \ --proxy-check-permission view --proxy-check-subject-type token \ To make the example work. How does the schema has to look like.

you'd need to define a

metric

type with a

view

permission:

definition metric {
  permission view = ...
}

how that permission is computed is up to you

a simple example might be

Is there a way to restrict the connection pool size for a postgres data store? I see the config argument

datastore-conn-max-open

but it doesn't appear to be working via the Kubernetes operator

can you show us how you specified it in the CR? I'm pretty sure it's possible because we use the operator ourselves to run authzed.com with such config

specifying it in the

SpiceDBCluster

using

datastoreConnMaxOpen: '5'

(not specifying the quotes failed initially). Afterwards, I see the deployment as the env var

SPICEDB_DATASTORE_CONN_MAX_OPEN

set to

'5'

Nice! For my information, what is the order of magnitude of the "slight delay"?

but if I look at active connections in the db, its showing the full 10

do you have 2 pods?

5s

by default

with two replicas, i'm seeing

20

connections

which datastore are you using?

postgres

then it's a matter of figuring if the configuration flags are being wired up in postgres. What you posted there seems like the right way of specifying it in the operator, and its also confirmed by the ENV variable also specified in the pod spec let me have a quick look

thanks!

@mgagliardo _ I think_ the max open conns is being overriden by the min open connections, which by default is 10. Can you also set the min conn flag to the same value and see if that fixes it?

so the min and max are both 10? The docs show 1 for the min default

you said you specified it to 5 initially, so let's specify both to 5?

the default min is 10 and max is 20

yup, I think that did it. Should

min

be 1 by default?;

ah

okay, different than the docs

we should add a warning for that

can you point me to where you found that in the docs?

ah, I see how that could be confusing