844600078504951838 #spicedb

Channels

zanzibar

test-forum

spicedb

user

01/27/2022, 7:04 PM

these aren't benchmarks but that service does guarantee a stable platform without noisy neighbors

user

01/27/2022, 7:04 PM

https://dashboard.bencher.orijtech.com/

ecordell

01/27/2022, 7:05 PM

yeah, maybe. and there are benchmarks in that suite that we just don't run, would be nice to run them and track them

vroldanbet

01/27/2022, 7:09 PM

unrelated question, I know y'all mentioned you rely a lot on pprof? what does your procedure look like? we are looking to streamline it. I found pyroscope.io to be very nice way to reduce the barrier to pprof

user

01/27/2022, 7:11 PM

Right now, I just port forward the port that serves pprof and then use

go tool pprof

to get a profile download, then I share it with the team on share.polarsignals.com. We've been meaning to setup Parca for a long term solution.

user

01/27/2022, 7:12 PM

https://github.com/parca-dev/parca

user

01/27/2022, 7:15 PM

The pyroscope folks were in our same YC batch though, so I'd be curious to hear your experience with their project. Parca is just trying to be very Prometheus-native and we're already pretty deeply invested in that stack

vroldanbet

01/27/2022, 7:16 PM

gotta run, will follow up tomorrow 👋🏻

vroldanbet

01/28/2022, 12:16 PM

@User saw https://github.com/authzed/spicedb/pull/376, are y'all working on making

spicedb

. work as a library? 👀

vroldanbet

01/28/2022, 12:17 PM

We are doing a prototype deployment here. It's really not meant for "large scale" deployments because it does not support federation like prometheus (one single pyroscope process, state/collection is coupled with the frontend process).

vroldanbet

01/28/2022, 12:18 PM

I checked Parca - UI seems less sophisticated. Most importantly, it talks about agents and eBPF, and that's more invasive. Pyroscope is the only one I found that understands pprof and is able to do "pull" style over pprof endpoints

vroldanbet

01/28/2022, 12:20 PM

From my perspective, pyroscope.io needs some serious redesign in order to be considered in a large-scale, multi-cluster environment

Jake

01/28/2022, 12:36 PM

Minimally, to support our spicedb enterprise offering

soufian044

01/28/2022, 3:42 PM

Hello guys, is this a valid relationship ? to say : group admin members can see all divisions

division:*#viewer@group:admin#member

in the playground i get : Error running validation - Incomplete response if not is there way to achieve this without having a 3rd type all_divisions ?

Joey

01/28/2022, 3:45 PM

hi @User - wildcards are only supported for subjects, not resources. you can say all users can see a particular division, but not the inverse

Joey

01/28/2022, 3:45 PM

if you want to allow a group to work for all divisions, the recommendation is to use an arrow, like:

Joey

01/28/2022, 3:46 PM

definition organization {
  relation admin: group#member
}

definition division {
  relation parent_org: organization
  relation viewer: group#member
  permission view = viewer + parent_org->admin
}

Joey

01/28/2022, 3:46 PM

you write a

parent_org

relationship for each division, and then you can add the group to the

admin

of the organization, and they would be granted permission to view all divisions for that organization

soufian044

01/28/2022, 4:39 PM

thanks, that is exactly how I've have it in the schema now

soufian044

01/28/2022, 4:40 PM

is this something that can be added to spicedb in the future ?

Joey

01/28/2022, 4:40 PM

speculative discussion is here: https://github.com/authzed/spicedb/issues/346

Sleipnir

01/28/2022, 10:11 PM

So I've got a rule on

deal

that says

permission view = investment->view + sponsor

. I do the permission check using

at_least_as_fresh

set to the max zedtoken of the deal and the user. This doesn't always work right away, because if an investment is added after the deal is created/modified, it has a later zedtoken than either deal or user, and when using

at_least_as_fresh

, spicedb queries postgres based on the max of that zedtoken and whatever it thinks is the latest transaction (e.g. if it hasn't updated from postgres since the last write to

relation_tuple_transaction

)

Sleipnir

01/28/2022, 10:11 PM

Does this imply that when I write an investment and update its zedtoken, I also have to update the zedtoken of the deal?

Sleipnir

01/28/2022, 10:17 PM

Or could I just query

relation_tuple_transaction

and serialize the zedtoken from that?

Joey

01/28/2022, 10:23 PM

@User how are you adding the investment? If

investment

is a relation on

deal

, I imagine if you update that rel, you'd also store the updated zedtoken for the

deal

, since

deal

is being modified as the resource

Sleipnir

01/28/2022, 10:28 PM

Straight db insert with a trigger to add zedtoken to the table.

Sleipnir

01/28/2022, 10:29 PM

It's... a long story (it's been told a few times in this channel) but because we're using a continuous DMS migration to sync our Postgres to our legacy MySQL database, we have to keep our spicedb data in sync with triggers. That involves some interesting problems we've already solved for like keeping the triggers fast, inserting rows in

relation_tuple_transaction

directly from the trigger, serializing ZedTokens in trigger code etc.

Sleipnir

01/28/2022, 10:31 PM

investment

has a foreign key index to

deal

on the column

deal_id

Joey

01/28/2022, 10:38 PM

yep

Joey

01/28/2022, 10:39 PM

my meta point is: if you're changing the relation on

deal

, then its zedtoken generally needs to update