14:01:17 <dkliban> #startmeeting Pulp Triage 2019-12-03
14:01:17 <dkliban> #info dkliban has joined triage
14:01:17 <dkliban> !start
14:01:17 <pulpbot> Meeting started Tue Dec  3 14:01:17 2019 UTC.  The chair is dkliban. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:17 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:01:17 <pulpbot> The meeting name has been set to 'pulp_triage_2019-12-03'
14:01:17 <pulpbot> dkliban: dkliban has joined triage
14:01:18 <pulpbot> dkliban: An error has occurred and has been logged. Check the logs for more information.
14:01:41 <dkliban> #info dkliban has joined triage
14:01:41 <dkliban> !start
14:01:41 <pulpbot> dkliban: Error: Can't start another meeting, one is in progress.
14:01:42 <pulpbot> dkliban: dkliban has joined triage
14:01:43 <pulpbot> dkliban: An error has occurred and has been logged. Check the logs for more information.
14:01:50 <dkliban> ok ... i think we are good
14:01:58 <bmbouter> thank you
14:02:07 <bmbouter> here is a link to the document with the use cases from last time https://docs.google.com/document/d/1byC3kXNqK0b4vA7iwkS9FDUdU60gfofixzxCMfLBt8E/edit#
14:02:12 <bmbouter> lmk if you don't have edit rights
14:02:37 <bmbouter> I just enabled edit rights so you may have to reload
14:02:40 <bmbouter> https://docs.google.com/document/d/1byC3kXNqK0b4vA7iwkS9FDUdU60gfofixzxCMfLBt8E/edit?usp=sharing
14:03:44 <bmbouter> I was reading over these and I thought of at least two use cases I wanted to also throw out there
14:04:44 <bmbouter> the first hsa to do with permissions assignment to new objects created
14:05:25 <dkliban> yep
14:05:46 <bmbouter> so a user receives a permission to create a new object, but what users get perms on that new object?
14:06:07 <bmbouter> I wanted to see if there were any strong expectations in this area from others
14:06:51 <dkliban> i would expect all users in my 'group' to have access
14:07:13 <dkliban> however, there might not be any users in my group
14:07:21 <dkliban> and it's just me in that group
14:07:50 <ttereshc> can we be more specific, I think for different object the logic of which perms to assign might be different
14:08:06 <ttereshc> e.g. uploaded file/artifact and repository
14:08:20 <ttereshc> can they follow the same perms startegy
14:08:22 <ttereshc> ?
14:08:29 <dkliban> i think so
14:09:00 <ttereshc> ok
14:09:43 <ttereshc> I create a repo and I want it to be managed by any users, not only from my group
14:10:08 <bmbouter> yes ^ is the second thing I was also pondering
14:11:25 <ttereshc> permissions upon creation - it's only available to my group. To make it public, I need to explicitly set perms that way.
14:11:26 <ttereshc> ?
14:11:37 <dkliban> yes, i think so
14:11:39 <bmbouter> +1
14:11:52 <ttereshc> I guess the strictest perms should be applied by default
14:11:58 <ttereshc> to be safe
14:12:21 <ttereshc> can I be a part of multiple perm groups?
14:12:32 <bmbouter> yes you should be able to be
14:12:36 <dkliban> i think so
14:12:54 <ttereshc> then it's trickier :/
14:13:18 <ttereshc> will I be able to provide permissions in the same call as I create a resource?
14:13:49 <bmbouter> I don't think so
14:13:52 <ttereshc> If I'm in multiple groups and I want the resource to be available only for one of them,how do I deal with that?
14:13:55 <bmbouter> although I don't have a clear suggestion on what to do
14:14:01 <bmbouter> this is also what I'm wondering
14:14:39 <bmbouter> I think there will be defaults probably, and the perms need to know the concept of "my user", "my group", "these groups" etc
14:14:57 <bmbouter> and this is kind of like a conceptual isolation level
14:15:39 <ttereshc> yeah
14:16:08 <dkliban> +1
14:16:32 <dkliban> so now we need to express this as a use case
14:16:32 <ttereshc> +1 for having defaults defined explicitly
14:16:56 <bmbouter> dkliban: this is what I was going for with "As a user, when I create new objects they are assigned expected permissions"
14:17:15 <ttereshc> As a user, I can configure default permissions for newly created objects?
14:17:55 <bmbouter> the persona there is a 'user' but then we need to talk about users having the right to make such changes
14:18:40 <ttereshc> As an administrator, I can configure default permissions for newly created object
14:18:47 <ttereshc> As a user, when I create new objects they are assigned default permissions
14:19:09 <bmbouter> this sounds pretty good
14:19:19 <ttereshc> assuming only admins can changes default perms
14:19:26 <ttereshc> *change
14:19:28 <bmbouter> well very good, there are just more open questions
14:19:34 <dkliban> lol
14:19:38 <bmbouter> let's use those two use cases
14:19:38 <ttereshc> (:
14:19:43 <dkliban> yes, let's
14:20:04 <bmbouter> added
14:21:24 <ttereshc> which questions do you think we need to answer now?
14:21:25 <bmbouter> ok what other use cases do folks want to discuss?
14:21:43 <bmbouter> I was hoping for a last call for use cases, and then a quick chat about next steps
14:22:33 <dkliban> i just have questions about existing use cases
14:22:48 <ttereshc> Does it make sense? As an administrator, I can grant the existing set of permissions to a user or a group of users.
14:23:00 <ttereshc> or is it covered by use case #2 from the last time
14:23:38 <bmbouter> I think slightly different, one is a specificaiton of not-yet-created object perms the other is a specification of an existing set
14:24:41 <dkliban> ttereshc: what is 'set of permissions' ?
14:24:42 <ttereshc> I can imagine that it would be convenient to create some sets of permissions and then grant different combinations to a user or a group
14:25:39 <ttereshc> e.g. set#1 - read access to all repos,  set#2 - write access to repoA and repoB
14:26:05 <dkliban> ttereshc: cool ... so i think there is 2 use cases there
14:26:18 <dkliban> As an administrator I can create a permission set.
14:26:32 <dkliban> As an administrator I can assign a permission set to a user or a group.
14:26:50 <bmbouter> my concern with this use csae is that I think it's going to preclude a lot of existing implementations
14:27:13 <bmbouter> as a nice to have this sounds great
14:28:06 <dkliban> what do you think ttereshc ?
14:28:27 <bmbouter> to clarify I hope these use cases are used to evaluate existing django/drf based rbac softwares so if it goes on the list to help inform that evaluation then +1
14:28:34 <ttereshc> I agree to keep it in nice-to-have category
14:28:52 <ttereshc> bmbouter, yeah, I understand
14:29:00 <dkliban> cool ... let's record then
14:29:06 <bmbouter> ttereshc: I feel like I'm stifling the convo, sorry for that
14:29:18 <bmbouter> +1 to record
14:29:27 <ttereshc> not at all, all good :)
14:29:32 <bmbouter> :)
14:29:53 <bmbouter> ty to Anynomous Blobfish for writing these out
14:30:20 <dkliban> lol
14:31:07 <bmbouter> ok other questions/convo?
14:31:30 <dkliban> As a user, I can grant a user/group of users permissions to promote to some environments (dev/test), but not others (production)
14:31:44 <dkliban> ^ do we want to make this use case more specific?
14:32:04 <dkliban> we should probably define what the environment is in pulp
14:32:30 <dkliban> i can see one user saying that a repository is an environment. another user saying that a distribution is an environment
14:32:43 <bmbouter> I think they both are
14:32:45 <bmbouter> lol
14:32:53 <dkliban> or both together
14:33:15 <bmbouter> this is similar to the grouping of permissions, at some point there is a convenience factor in grouping things together
14:33:37 <bmbouter> but I am concerned if we focus on that we'll miss the actual raw permissions in all their detail
14:34:10 <dkliban> yep
14:34:26 <bmbouter> I think of this as calling out the need for "view-level permissions support" in that syncing on a repository is an action, not a CRUD perm on the repository
14:34:44 <bmbouter> CRUD on a distirbution though is just CRUD so I think of that as "object level permissions"
14:34:58 <bmbouter> and my takeaway is I'm seeing use cases for both
14:35:18 <dkliban> yep ... so we need a use case that specifies the view level permissions
14:37:42 <ttereshc> I'm a bit confused what is view-level. view as read, or view as django views - other actions than crud?
14:38:35 <bmbouter> think "action endpoints" as view-level
14:38:36 <dkliban> ttereshc: view as in django view
14:38:40 <bmbouter> yes
14:38:54 <dkliban> user is allowed or not allowed to sync
14:39:00 <bmbouter> for example sync, you're not actually modifying the repo's data itself
14:39:02 <ttereshc> cool, thanks
14:39:17 <dkliban> do we have any other action endpoints?
14:39:24 <bmbouter> modify
14:39:30 <dkliban> yep
14:39:51 <bmbouter> upload
14:39:57 <ttereshc> copy
14:40:02 <ttereshc> ah it's modify
14:41:41 <ttereshc> It's hard to separate crud perms from action perms, because to publish a repo, you need to Create a publication and/or distribution.
14:41:59 <ttereshc> I mean from the user point of view
14:43:15 <bmbouter> I think they'll get all those
14:43:27 <bmbouter> get meaning receive the ability to control
14:43:49 <ttereshc> I'm thinking how to phrase properly the use case :)
14:44:27 <bmbouter> the permission is more the creation/deletion of repository versions
14:44:46 <bmbouter> and that isn't a CRUD operaiton on a repository, and we don't want users to think about repository versions directly
14:45:34 <bmbouter> As an administrator, permissions are available to allow/deny the creation/deletion of a repository version as a repository permission
14:46:37 <bmbouter> this basically handles all repository content change operation RBAC checking
14:47:14 <ttereshc> maybe it can be "As a administrator, I can allow/deny modification of repository content"?
14:47:36 <ttereshc> if we don't want users to think about repo versions
14:47:39 <bmbouter> let's go with that
14:48:27 <bmbouter> ok other thoughts on this list?
14:49:03 <ttereshc> And in the use case #4, there are "permissions to promote". Does it mean permission to create publication/distribution for a specific repo?
14:50:18 <ttereshc> I'm just thinking that it's likely not easy to implement those.
14:50:41 <bmbouter> I think of it as publication creation for the repo, that is another view level
14:50:59 <dkliban> promoting can mean 2 things: permission to copy repo A to a repo i have permission to control. or permission to create a publication using repo A
14:51:19 <ttereshc> ok
14:51:21 <ttereshc> thanks
14:51:30 <ttereshc> I don't have any other questions at the moment
14:53:00 <dkliban> bmbouter: do you have any questions at this time?
14:53:22 <bmbouter> I don't. I'd like to look at some of the permission options and write up and send it to the list
14:53:29 <bmbouter> s/options/softwares/
14:53:48 <bmbouter> so we can conclude if there are no other discussions
14:54:10 <ttereshc> +1
14:54:18 <dkliban> that would be great
14:54:21 <bmbouter> go for it
14:54:25 <dkliban> #endmeeting
14:54:25 <dkliban> !end