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