844600078504951838 #spicedb

Channels

Jake

10/19/2022, 7:35 PM

e.g.

permission reader = nil // Not sure what this should be yet

symion

10/19/2022, 8:29 PM

Are there any resourcing guidelines for a spicedb deployment? is it CPU heavy or memory heavy? does it do better with more cpu cores, or 1 core and more instances?

Joey

10/19/2022, 8:31 PM

more CPU cores is generally better. Memory is primarily for the cache size and is configurable

symion

10/19/2022, 8:32 PM

whats a sane starting point for cache size? 1G?

symion

10/19/2022, 8:33 PM

10G?

Joey

10/19/2022, 8:33 PM

very much depends on your traffic pattern

Joey

10/19/2022, 8:34 PM

the cache will be invalidated after ~5s anyway (the default window)

Joey

10/19/2022, 8:36 PM

1G is likely larger than you need by a good amount, but if you have the memory available on the machine, it can't really hurt to give it to it

Joey

10/19/2022, 8:36 PM

again, depends on traffic

__alexb__

10/19/2022, 11:36 PM

Hi everybody, we're randomly getting this error when using SpiceDB with Postgres as a datastore

Copy code

{"level":"error","requestID":"4fb88c480756c86269cef27e5015b574","error":"unable to read namespace config: context canceled","time":"2022-10-19T23:01:14Z","message":"received unexpected error"}
 {"level":"error","grpc.component":"server","grpc.method":"CheckPermission","grpc.method_type":"unary","grpc.service":"authzed.api.v1.PermissionsService","peer.address":"192.168.32.4:46070","protocol":"grpc","requestID":"4fb88c480756c86269cef27e5015b574","grpc.start_time":"2022-10-19T23:01:14Z","grpc.code":"Unknown","grpc.error":"unable to read namespace config: context canceled","grpc.time_ms":"29.173","time":"2022-10-19T23:01:14Z","message":"finished call"}

the same issue was mentioned here before by a couple of people, but I didn't find any advice how this can be solved. Just like in the previously reported cases we started to get this issue in integration tests. Switching to

serve-testing

helps with the tests but we've seen the same error a couple of times in the live system as well. We've tried to adjust lots of settings like SPICEDB_NS_CACHE_DISABLED, SPICEDB_DATASTORE_MAX_TX_RETRIES, etc., but nothing has made our tests reliable. The tests aren't heavy at all, we create less than 100 relatioships and do various calls to check permissions and lookup resources. We run them using docker-compose and the official SpiceDB Python client. Any hints would be really apreciated.

Jake

10/20/2022, 1:31 AM

It's almost for sure a consistency error. Make your check calls with immediate consistency, implement zookies, or set

--datastore-revision-quantization-interval

to 0

__alexb__

10/20/2022, 8:52 AM

sorry, I didn't mention this in the first place - we run both tests and prod with

SPICEDB_CONSISTENCY=fully_consistent

, adding

--datastore-revision-quantization-interval=0

didn't have any noticeable effect - out of 10 test runs 2-3 still fail in seemingly random places - both on CheckPermission and WriteRelationships with the error I posted above

vroldanbet

10/20/2022, 8:55 AM

any chances you could share a test that reproduces with us?

__alexb__

10/20/2022, 8:58 AM

let me see if we can come up with some minimalistic version that we can share and that still reproduces the problem, thanks for your help

williamdclt

10/20/2022, 10:58 AM

FWIW I'm seeing these random

unable to read namespace config: context canceled

in live environment too. They've not been quite problematic enough to bring it up here yet, but the time would have come at some point 😉 I don't understand how we'd have "a consistency error" here? (and as a side-note, seems like the logging can be improved here to make the root cause clearer?)

Jake

10/20/2022, 1:23 PM

AlexB what version of SpiceDB are you using?

Jake

10/20/2022, 1:27 PM

@__alexb__ And you mentioned switching to

serve-testing

which uses the memdb datastore, do you still get the error after that switch or only when running with the postgres datastore?

herb2193

10/20/2022, 2:33 PM

Hello. Can you point me to an example of contextual queries. i.e. github org:a and org:b both have beth as a member. org:a bought plans that are expensive and beth can only have access to what that plan provides in context of org:a

Jake

10/20/2022, 2:37 PM

Presumably you would start your query from the org, e.g.

Copy code

definition organization {
  relation member: user // beth
  permission do_an_expensive_thing = member
}

Jake

10/20/2022, 2:38 PM

the check would be like

resource: organization:org_a, permission:do_an_expensive_thing subject: user:beth

__alexb__

10/20/2022, 2:45 PM

we tested with v1.13.0 and v1.12.0 (using the images from docker hub) and saw no difference between them in this regard, with

serve-testing

it works just fine, so it's only postgres

herb2193

10/20/2022, 2:48 PM

I also have another model in mind where I can get rid of a user (cut the head off the snake so to speak) in one hit. The use case is that beth has been compromised and beth's access to the entire system has to be revoked. (think revoke refresh_tokens in OAuth2) My access_token/refresh_token carry only 2 things (subject:beth, integrity_id:1234) My thought is. 1. a user_repo where all users reside (just like github) beth is a member or user_repo and also a member or integrity:1234 if you ask is beth in user_repo, it can only be yes if beth is in both. So the user_repo object is dependent on beth being in integrity:1234 if I kick beth out of integrity:1234, there is no more beth. To get beth back, I create a new object integrity:2222 and add beth to that one. I then let user_repo have a relationship with integrity:2222 beth is back. All those access_token(s) and refresh_token(s) that are still carrying and producing beth + integrity_id:1234 are useless, thus revoked in a single hit.

Jake

10/20/2022, 4:28 PM

@williamdclt @__alexb__ we have a fix: https://github.com/authzed/spicedb/pull/925

Prchowdh

10/20/2022, 4:38 PM

Any plan to support operation between relation? Something like

Copy code

definition usergroup {
    relation admin: user
    relation member: user + admin
}

Joey

10/20/2022, 5:02 PM

what does

user + admin

mean?

Joey

10/20/2022, 5:03 PM

if you mean to have

member

include members and admins, you'd do:

Copy code

definition usergroup {
  relation admin: user
  relation direct_member: user
  permission member = admin + direct_member
}

Joey

10/20/2022, 5:03 PM

and then use

member

in your other relation

Joey

10/20/2022, 5:03 PM

Copy code

definition document {
  relation viewer: user | usergroup#member
}

Prchowdh

10/20/2022, 5:07 PM

Thanks . usergroup#member --> i thought only relation can be referred like this

Joey

10/20/2022, 5:08 PM

relations and permissions, if used as part of a subject