You need to run `spicedb migrate`
# spicedb
j
You need to run
spicedb migrate
r
post migration I see following error in the log
Copy code
{
  "level": "error",
  "module": "pgx",
  "args": [
    "relation_tuple"
  ],
  "err": "can't scan into dest[0]: -1 is less than zero for uint64",
  "pid": 90447,
  "sql": "SELECT reltuples FROM pg_class WHERE relname = $1",
  "time": "2022-04-28T11:08:59Z",
  "message": "Query"
}
I have dispatcher enabled, 3 replicas with external db and port forwarding enabled on 8443 on deploymet to test rest end point Check/ Expand / Lookup which still fails
j
Have you written any relationships yet?
r
Yes and able to fetch those as well
j
What version of pg are you using?
And do you have AUTO VACUUM enabled?
r
14
No I havent explicit
j
I’ll take a look, but that error shouldn’t cause you any functionality problems.
r
I can push the helm folder on git if you can have a look , been trying for quite some time but I don't see the dispatcher working out of box easily.
as said , only lookup / expand / check not working
j
Them not working should be unrelated to that error
Yeah go ahead and push the helm, I will take a look when I can
r
ok gr8, thanks
https://github.com/romilshahdev/spicedb/blob/main/README.md This is where I have the steps done. Plz let me know if you need any more details , thanks
j
just to clarify, you're using
authz
as the namespace for the spicedb service as well, right?
I think you just need to add a flag to your
args:
for
--dispatch-cluster-enabled
then you should see this in your log lines:
9:15AM INF grpc server started listening addr=:50053 network=tcp prefix=dispatch-cluster workers=0
let me know if that works
r
Hey, Jake, definitely adding this flag started generating the above-said message of a dispatch-cluster workers in the log. thanks for looking at the file.
A follow-up question, I have 3 replicas up and running with Postgres In order to access the rest endpoint, I did port forward on deployment
Copy code
kubectl port-forward deployment/spicedb 8443:8443
After this observation is still the. same the Check api fails , but others pass Since I have a local postgres running , created a postgres service to externalize the endpoint
Copy code
kind: Service
apiVersion: v1
metadata:
  name: postgres
  namespace: default
spec:
  type: ExternalName
  
  externalName: host.docker.internal
  ports:
    - name: port
      port: 5432
and connection URI is :
Copy code
"postgres://postgres:passw0rd@host.docker.internal:5432/postgres?sslmode=disable"
Wondering why only check / expand still failing
j
what is the error?
r
seems it just times out
internal dispatching mostly not taking place , may be
j
can you copy and paste the client side and server side logs?
r
sure
I am using postman to just hit. thecheck api
Copy code
curl --location --request POST 'http://localhost:8443/v1/permissions/check' \
--header 'Authorization: Bearer graphToken' \
--header 'Content-Type: application/json' \
--data-raw '{
  "consistency": {
    "minimizeLatency": true
  },
  "resource": {
    "objectType": "document",
    "objectId": "topsecret9"
  },
  "permission": "view",
  "subject": {
    "object": {
      "objectType": "user",
      "objectId": "alice"
    }
  }
}
'
appreciate you looking into it.
Copy code
{"level":"error","module":"pgx","args":["relation_tuple"],"err":"can't scan into dest[0]: -1 is less than zero for uint64","pid":54025,"sql":"SELECT reltuples FROM pg_class WHERE relname = $1","time":"2022-04-28T19:44:35Z","message":"Query"}
{"level":"warn","error":"unable to query DB stats: unable to read relationship count: can't scan into dest[0]: -1 is less than zero for uint64","time":"2022-04-28T19:44:35Z","message":"unable to initialize telemetry collector"}
These are bootup time logs, else for check api it just times out
Any view @Jake, if the error above gives any clue to the check api timeout
j
I see successful check calls from the server side, right?
I don't see any logs for Expand requests
oh nevermind, those Checks are health checks
can you try the requests using zed or one of the grpc clients?
i would like to isolate whether it's the grpc gateway or the actual server configuration causing a problem
r
Below API runs successfully 1. http://localhost:8443/v1/relationships/read 2. http://localhost:8443/v1/relationships/write 3. http://localhost:8443/v1/relationships/read API listed below fails 1. http://localhost:50051/v1/permissions/check 2. http://localhost:8443/v1/permissions/expand 3. http://localhost:8443/v1/permissions/resources Note the same listed operation via Zed client is also failing Below are the steps that I followed : 1. Run 2 pods as replica, configuration same as the one I shared in GIT repo 2. Configure port forward
Copy code
kubectl port-forward deployment/spicedb 8443:8443 50051:50051
Run above api via rest or via Zed , observation is either they timeout or sometimes fails with below atach logs
Copy code
zed permission check document:topsecret9 view user:alice
10 Views