14:30:51 <fao89> #startmeeting Pulp Triage 2020-06-05 14:30:51 <fao89> #info fao89 has joined triage 14:30:51 <fao89> !start 14:30:51 <pulpbot> Meeting started Fri Jun 5 14:30:51 2020 UTC. The chair is fao89. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:30:51 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:30:51 <pulpbot> The meeting name has been set to 'pulp_triage_2020-06-05' 14:30:51 <pulpbot> fao89: fao89 has joined triage 14:30:58 <mikedep333> #info mikedep333 has joined triage 14:30:58 <mikedep333> !here 14:30:58 <pulpbot> mikedep333: mikedep333 has joined triage 14:31:04 <ppicka> #info ppicka has joined triage 14:31:04 <ppicka> !here 14:31:04 <pulpbot> ppicka: ppicka has joined triage 14:31:07 <fao89> !next 14:31:08 <fao89> #topic https://pulp.plan.io/issues/6905 14:31:08 <pulpbot> fao89: 3 issues left to triage: 6905, 6898, 6893 14:31:09 <pulpbot> RM 6905 - daviddavis - NEW - The pr processor sets issues to POST that are associated with "ref" (eg "ref #1234") 14:31:10 <pulpbot> https://pulp.plan.io/issues/6905 14:31:20 <daviddavis> #info daviddavis has joined triage 14:31:20 <daviddavis> !here 14:31:20 <pulpbot> daviddavis: daviddavis has joined triage 14:31:42 <ppicka> I'd add how 'correct behaviour' should looks like 14:31:51 <dkliban> #info dkliban has joined triage 14:31:51 <dkliban> !here 14:31:51 <pulpbot> dkliban: dkliban has joined triage 14:31:58 <fao89> #idea Proposed for #6905: Leave the issue as-is, accepting its current state. 14:31:58 <fao89> !propose accept 14:31:58 <pulpbot> fao89: Proposed for #6905: Leave the issue as-is, accepting its current state. 14:32:19 <daviddavis> correct behavior would be that the status doesn't get updated 14:32:37 <daviddavis> I can add that to the issue 14:32:42 <daviddavis> do others agree? 14:33:12 <bmbouter> #info bmbouter has joined triage 14:33:12 <bmbouter> !here 14:33:12 <pulpbot> bmbouter: bmbouter has joined triage 14:33:22 <bmbouter> I agree 14:33:25 <dkliban> daviddavis: i agree 14:33:29 <daviddavis> +1 14:33:29 <fao89> I don't have strong opinion on that 14:33:43 <daviddavis> we can accept and I'll update the issue then 14:33:54 <fao89> #agreed Leave the issue as-is, accepting its current state. 14:33:54 <fao89> !accept 14:33:54 <pulpbot> fao89: Current proposal accepted: Leave the issue as-is, accepting its current state. 14:33:55 <fao89> #topic https://pulp.plan.io/issues/6898 14:33:55 <pulpbot> fao89: 2 issues left to triage: 6898, 6893 14:33:56 <pulpbot> RM 6898 - Dine - NEW - Pulp 2 - REST API for Search ignores critera or raises errors when field or filter is specified 14:33:57 <pulpbot> https://pulp.plan.io/issues/6898 14:35:45 <dkliban> this is pulp 2 14:35:56 <dkliban> let's skip for now 14:36:08 <dkliban> i'll take a look at this after triage 14:36:09 <dalley> #info dalley has joined triage 14:36:09 <dalley> !here 14:36:09 <pulpbot> dalley: dalley has joined triage 14:36:17 <dkliban> we might want to close 14:36:21 <dkliban> as wont fix 14:36:36 <dkliban> or as worksforme and provide the correct way to use it 14:36:50 <dkliban> plus this is a really old version of pulp 14:36:54 <dkliban> 2.16.4 14:37:00 <fao89> !skip 14:37:01 <fao89> #topic https://pulp.plan.io/issues/6893 14:37:01 <pulpbot> fao89: 1 issues left to triage: 6893 14:37:03 <pulpbot> RM 6893 - fao89 - NEW - Release script does not work with z-stream releases 14:37:04 <pulpbot> https://pulp.plan.io/issues/6893 14:37:12 <dkliban> accept and add to sprint? 14:37:51 <daviddavis> I thought this was the correct behavior? 14:38:28 <fao89> after branching I started to think it was right 14:39:04 <dkliban> yeah ... i didn't have a problem when i released pulp_container eysterday 14:39:28 <daviddavis> worksforme? 14:39:32 <fao89> +1 14:39:46 <fao89> #idea Proposed for #6893: close as worksforme 14:39:46 <fao89> !propose other close as worksforme 14:39:46 <pulpbot> fao89: Proposed for #6893: close as worksforme 14:40:13 <fao89> #agreed close as worksforme 14:40:13 <fao89> !accept 14:40:13 <pulpbot> fao89: Current proposal accepted: close as worksforme 14:40:14 <pulpbot> fao89: No issues to triage. 14:40:34 <fao89> Open floor - https://hackmd.io/SVCMjpwXTfOMqF2OeyyLRw 14:40:50 <fao89> topic: Redmine Simplification 14:40:55 <daviddavis> +1 from me 14:41:00 <fao89> bmbouter ^ 14:41:50 <bmbouter> ty 14:42:27 <fao89> +1 for me 14:42:45 <bmbouter> I'm also in favor but I proposed 14:42:58 <fao89> next topic? 14:43:33 <daviddavis> there's a small quorum here today. does it make sense to just email pulp-dev about removing these fields? I am fine either way 14:43:35 <fao89> topic: Is there a way to turn off notifications for a particular issue in redmine 14:43:46 <daviddavis> I added this topic 14:43:56 <bmbouter> I will handle the redmine changes 14:43:59 <daviddavis> I didn't see a way to do this? 14:44:15 <bmbouter> there is not a way to do this is my understanding 14:44:21 <daviddavis> :/ 14:44:39 <daviddavis> that sucks. oh well. 14:44:56 <bmbouter> indeed 14:45:09 <bmbouter> email filter? 14:45:19 <bmbouter> that's a mechanism of last resort though 14:45:36 <bmbouter> and eventually this will get better because once we make pulp a place where spam doesn't live long they will stop posting 14:45:40 <bmbouter> is my belief 14:45:47 <daviddavis> +1 14:46:07 <fao89> next: django-admin for pulp3, probably needed for RBAC 14:46:42 <daviddavis> who added this 14:46:55 * daviddavis guesses bmbouter 14:47:05 <fao89> daviddavis is right 14:47:18 <bmbouter> I added this 14:47:25 <daviddavis> :) 14:47:34 <fao89> s/open floor agenda/bmbouter agenda 14:47:37 <daviddavis> haha 14:47:40 <fao89> just kidding! 14:47:46 <bmbouter> haha right 14:47:54 <bmbouter> so rbac is progressing pretty well 14:48:16 <fao89> bmbouter++ 14:48:16 <pulpbot> fao89: bmbouter's karma is now 275 14:48:45 <bmbouter> I suspect the PoC will wrap up by the end of next week 14:48:54 <bmbouter> and I'll schedule a meeting to review it and post the code, etc 14:49:04 <bmbouter> but here's what I'm learning that is relavent for django-admin 14:50:04 <bmbouter> so admins will need to be able to assign permissions to users and groups 14:50:40 <bmbouter> even when users and groups are external to pulp I'm seeing the strategy is that they get added into django's user and groups tables at login time 14:51:19 <bmbouter> so the external source of identity management, e.g. ldap, active directory, kerberos, etc is still "in charge" but practically speaking you can't have those systems meet permissions kept in the django db without this "replicaiton" 14:52:51 <bmbouter> so to fulfill the use cases of "an administrator can apply users and group permissions" I think django-admin is how it will be done 14:53:00 <bmbouter> and this is how django-guardian does it for example 14:53:06 <bmbouter> https://django-guardian.readthedocs.io/en/stable/overview.html 14:53:28 <bmbouter> it says "Django admin's integraiton" and I've been testing it, it's going to fulfill that part of the use cases completely 14:53:43 <daviddavis> does that mean users for example will be created with django-admin? 14:54:22 <bmbouter> yes it does upon first login (or ahead of time by an admin) the user is added to the users table 14:54:45 <daviddavis> ok 14:55:49 <daviddavis> that sounds good to me 14:56:16 <dkliban> +1 14:56:59 <bmbouter> I also agree 14:57:10 <bmbouter> so this calls into question the future of drf browseable api vs django-admin 14:57:33 <bmbouter> here's an issue where we say why we don't want to use django-admin w/ reasons: https://pulp.plan.io/issues/6475 14:58:01 <bmbouter> we could use django-admin in a very-limited way: read-write for these users/perms things and nothing else 14:58:21 <bmbouter> or read-write for these uers/perms and read-only for the other objects in pulp 14:58:56 <bmbouter> so I want to ask folks to think about is: assuming we have django-admin for parts of pulp, why would we continue with the drf browseable api? 14:58:57 <daviddavis> just so I understand, django-admin is the cli tool? 14:59:10 <bmbouter> oh no, django-admin is a web interface 14:59:15 <daviddavis> ohh 14:59:33 <bmbouter> and that's my concern is having two web interfaces that do basically the same thing 14:59:40 <daviddavis> yup 15:00:15 <daviddavis> do I have to use a web interface to manage users/permissions/etc because i never use a web interfact 15:00:19 <daviddavis> interface 15:00:48 <bmbouter> I think we'll need to have API also but maybe not on day 1 15:00:57 <bmbouter> I haven't gotten that far into the PoC so it may work already 15:01:03 <daviddavis> ok 15:01:27 <daviddavis> going back to using two web interfaces, I don't have a strong pref since I don't use web uis but having two seems suboptimal 15:02:00 <bmbouter> I agree 15:02:35 <bmbouter> I think figuring out how to move through that problem will be easier when we have a concrete example of django-guardian's use of django-admin along w/ the PRs from alikins which add additional models to django-admin and comparing against what DRF is offering 15:02:43 <bmbouter> so in other words we'll know a lot more later 15:02:47 <dkliban> yeah 15:02:52 <dkliban> let's not make any decisions right now 15:02:58 <bmbouter> agreed 15:03:05 <bmbouter> the main thing I wanted to share is ... django-admin is coming 15:03:13 <dkliban> yep 15:03:14 <dkliban> sounds like it 15:03:17 <daviddavis> is it called django-admin? that's super confusing 15:03:37 <dkliban> it's a Web UI 15:03:42 <bmbouter> yup 15:03:45 <daviddavis> and a django tool 15:03:46 <dkliban> not the binary 15:03:48 <bmbouter> it's probably one of the best parts of django 15:04:04 <daviddavis> isn't it called like "Django admin" vs "django-admin" 15:04:08 <bmbouter> https://duckduckgo.com/?t=ffab&q=django+admin&iax=images&ia=images 15:04:17 <bmbouter> yeah it's Django Admin I'm saying it worng 15:04:22 <daviddavis> ok thanks 15:06:31 <bmbouter> that's all I had 15:06:37 <bmbouter> for me agenda :) 15:06:39 <bmbouter> my 15:07:26 <fao89> #endmeeting 15:07:26 <fao89> !end