14:30:40 <fao89> #startmeeting Pulp Triage 2020-08-18
14:30:40 <fao89> #info fao89 has joined triage
14:30:40 <fao89> !start
14:30:40 <pulpbot> Meeting started Tue Aug 18 14:30:40 2020 UTC.  The chair is fao89. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:30:40 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:30:40 <pulpbot> The meeting name has been set to 'pulp_triage_2020-08-18'
14:30:40 <pulpbot> fao89: fao89 has joined triage
14:30:54 <ppicka> #info ppicka has joined triage
14:30:54 <ppicka> !here
14:30:54 <pulpbot> ppicka: ppicka has joined triage
14:31:05 <bmbouter> #info bmbouter has joined triage
14:31:05 <bmbouter> !here
14:31:05 <pulpbot> bmbouter: bmbouter has joined triage
14:31:33 <dkliban> #info dkliban has joined triage
14:31:33 <dkliban> !here
14:31:33 <pulpbot> dkliban: dkliban has joined triage
14:31:57 <fao89> !next
14:31:58 <fao89> #topic https://pulp.plan.io/issues/7330
14:31:58 <pulpbot> fao89: 9 issues left to triage: 7330, 7329, 7326, 7325, 7324, 7323, 7321, 7319, 7316
14:31:59 <pulpbot> RM 7330 - ipanova@redhat.com - NEW - Failure during generate of token authentication private key
14:32:00 <pulpbot> https://pulp.plan.io/issues/7330
14:32:01 <ttereshc> #info ttereshc has joined triage
14:32:01 <ttereshc> !here
14:32:02 <pulpbot> ttereshc: ttereshc has joined triage
14:32:17 <fao89> #idea Proposed for #7330: accept and add to sprint
14:32:17 <fao89> !propose other accept and add to sprint
14:32:17 <pulpbot> fao89: Proposed for #7330: accept and add to sprint
14:32:22 <dalley> #info dalley has joined triage
14:32:22 <dalley> !here
14:32:22 <pulpbot> dalley: dalley has joined triage
14:32:29 <daviddavis> #info daviddavis has joined triage
14:32:29 <daviddavis> !here
14:32:29 <pulpbot> daviddavis: daviddavis has joined triage
14:32:42 <dkliban> +1
14:32:49 <ttereshc> +1
14:33:22 <fao89> #agreed accept and add to sprint
14:33:22 <fao89> !accept
14:33:23 <fao89> #topic https://pulp.plan.io/issues/7329
14:33:23 <pulpbot> fao89: Current proposal accepted: accept and add to sprint
14:33:24 <pulpbot> fao89: 8 issues left to triage: 7329, 7326, 7325, 7324, 7323, 7321, 7319, 7316
14:33:25 <pulpbot> RM 7329 - lmjachky - NEW - When creating a permission using invalid parameters, an internal server error is raised
14:33:26 <pulpbot> https://pulp.plan.io/issues/7329
14:33:36 <ttereshc> #idea Proposed for #7329: accept and add to sprint
14:33:36 <ttereshc> !propose other accept and add to sprint
14:33:36 <pulpbot> ttereshc: Proposed for #7329: accept and add to sprint
14:33:47 <daviddavis> +1
14:33:49 <ppicka> +1
14:33:54 <fao89> #agreed accept and add to sprint
14:33:54 <fao89> !accept
14:33:54 <pulpbot> fao89: Current proposal accepted: accept and add to sprint
14:33:55 <fao89> #topic https://pulp.plan.io/issues/7326
14:33:55 <pulpbot> fao89: 7 issues left to triage: 7326, 7325, 7324, 7323, 7321, 7319, 7316
14:33:56 <pulpbot> RM 7326 - Rekha - NEW - Lottery sambad
14:33:57 <pulpbot> https://pulp.plan.io/issues/7326
14:34:01 <daviddavis> add to sprint!
14:34:06 <lmjachky> +1
14:34:09 <bmbouter> +1
14:34:21 <fao89> !skip
14:34:22 <fao89> #topic https://pulp.plan.io/issues/7325
14:34:22 <pulpbot> fao89: 6 issues left to triage: 7325, 7324, 7323, 7321, 7319, 7316
14:34:23 <pulpbot> RM 7325 - dkliban@redhat.com - NEW - release.py --help checks redmine issues before returning help text
14:34:24 <pulpbot> https://pulp.plan.io/issues/7325
14:34:36 <daviddavis> story
14:35:26 <ttereshc> it's a nice feature, though it already happens if you just run it
14:35:45 <fao89> #idea Proposed for #7325: convert to story
14:35:45 <fao89> !propose other convert to story
14:35:45 <pulpbot> fao89: Proposed for #7325: convert to story
14:36:35 <dkliban> it's not a sotry
14:36:37 <dkliban> this is a bug
14:36:41 <daviddavis> I see
14:36:56 <dkliban> the help text should just show up without any interaction with redmine
14:37:04 <dkliban> it takes a while for the help text to show up
14:37:15 <fao89> #idea Proposed for #7325: Leave the issue as-is, accepting its current state.
14:37:15 <fao89> !propose accept
14:37:15 <pulpbot> fao89: Proposed for #7325: Leave the issue as-is, accepting its current state.
14:37:18 <ttereshc> ah I also read it as a story
14:37:21 <ttereshc> :)
14:37:24 <daviddavis> it's not totally clear from teh issue if this is the rescommendation or the actual existing functionality
14:37:34 <dkliban> this is what happens now
14:37:39 <dkliban> and it shouldnt'
14:37:46 <daviddavis> right, I am saying though that's unclear
14:37:52 <dkliban> i'll update
14:37:55 <daviddavis> thanks
14:37:59 <daviddavis> +1 to accept
14:38:11 <ttereshc> thanks for updatingthe issue
14:38:43 <fao89> #agreed Leave the issue as-is, accepting its current state.
14:38:43 <fao89> !accept
14:38:43 <pulpbot> fao89: Current proposal accepted: Leave the issue as-is, accepting its current state.
14:38:43 <fao89> #topic https://pulp.plan.io/issues/7324
14:38:44 <pulpbot> fao89: 5 issues left to triage: 7324, 7323, 7321, 7319, 7316
14:38:45 <pulpbot> RM 7324 - AlexHall - NEW - Software House Professionals
14:38:46 <pulpbot> https://pulp.plan.io/issues/7324
14:38:51 <fao89> !skip
14:38:52 <fao89> #topic https://pulp.plan.io/issues/7323
14:38:52 <pulpbot> fao89: 4 issues left to triage: 7323, 7321, 7319, 7316
14:38:54 <pulpbot> RM 7323 - AlexMiller - NEW - Hire Logo Designer
14:38:55 <pulpbot> https://pulp.plan.io/issues/7323
14:39:03 <dalley> we should have a !spam command
14:39:04 <daviddavis> lots of spammers named Alex
14:39:06 <daviddavis> ha yea
14:39:08 <bmbouter> yup
14:39:16 <dalley> actually serious though lol
14:39:19 <dalley> we should
14:39:24 <fao89> !skip
14:39:25 <fao89> #topic https://pulp.plan.io/issues/7321
14:39:25 <pulpbot> fao89: 3 issues left to triage: 7321, 7319, 7316
14:39:26 <pulpbot> RM 7321 - Aant - NEW - pulp_rpm: Cannot synchronize repos behind proxy [Network is unreachable]
14:39:27 <pulpbot> https://pulp.plan.io/issues/7321
14:41:33 <dkliban> we should accept and investigate
14:41:47 <bmbouter> agree but how
14:41:48 <dkliban> i don't think we have any tests with a proxcy
14:41:52 <daviddavis> or investigate and then accept
14:41:59 <bmbouter> yeah das better
14:42:12 <daviddavis> +1 to proxy tests
14:42:13 <dkliban> bmbouter: we should investigate by using a proxy running in a container
14:42:37 <fao89> it is on operator category
14:42:51 <dkliban> let's change that
14:43:13 <bmbouter> dkliban: good idea
14:43:15 <fao89> I'm wondering if they are really using the operator
14:43:21 <dkliban> they are not
14:43:34 <dkliban> i am guessing that was just a mistake
14:44:36 <ttereshc> definitions for different categories would help so users are not confused what it means
14:44:37 <bmbouter> agreed
14:44:41 <fao89> so what would be the action? skip?
14:45:11 <dkliban> skip for now, but we need someone to investigate this
14:45:17 <dkliban> and i can't do it
14:45:24 <dkliban> at least not till next week
14:45:35 <daviddavis> +1
14:46:07 <daviddavis> I might have some time next week after I finish my devconf presentation and the kickstart export tests
14:46:36 <fao89> !skip
14:46:37 <pulpbot> fao89: 2 issues left to triage: 7319, 7316
14:46:37 <fao89> #topic https://pulp.plan.io/issues/7319
14:46:38 <pulpbot> RM 7319 - daviddavis - NEW - PulpTemporaryFile aren't being stored in /var/lib/pulp
14:46:39 <pulpbot> https://pulp.plan.io/issues/7319
14:46:52 <daviddavis> bmbouter fao89 any thoughts here?
14:46:53 <fao89> #idea Proposed for #7319: accept and add to sprint
14:46:53 <fao89> !propose other accept and add to sprint
14:46:53 <pulpbot> fao89: Proposed for #7319: accept and add to sprint
14:46:56 <daviddavis> +1
14:47:14 <bmbouter> +1
14:47:23 <fao89> #agreed accept and add to sprint
14:47:23 <fao89> !accept
14:47:23 <pulpbot> fao89: Current proposal accepted: accept and add to sprint
14:47:24 <fao89> #topic https://pulp.plan.io/issues/7316
14:47:24 <pulpbot> fao89: 1 issues left to triage: 7316
14:47:25 <pulpbot> RM 7316 - lmjachky - POST - Files are not being deleted from storage when calling the method delete()
14:47:26 <pulpbot> https://pulp.plan.io/issues/7316
14:47:41 <fao89> #idea Proposed for #7316: accept and add to sprint
14:47:41 <fao89> !propose other accept and add to sprint
14:47:41 <pulpbot> fao89: Proposed for #7316: accept and add to sprint
14:47:51 <daviddavis> +1
14:47:54 <ppicka> +1
14:47:56 <fao89> #agreed accept and add to sprint
14:47:56 <fao89> !accept
14:47:56 <pulpbot> fao89: Current proposal accepted: accept and add to sprint
14:47:57 <bmbouter> +1
14:47:58 <pulpbot> fao89: No issues to triage.
14:48:12 <fao89> open floor!
14:48:24 <fao89> https://hackmd.io/@pulp/triage/edit
14:48:40 <fao89> topic: Adoption of django-cleanup
14:48:53 <daviddavis> so to fix https://pulp.plan.io/issues/7316 we were looking at django-cleanup
14:49:01 <daviddavis> here's the PR https://github.com/pulp/pulpcore/pull/844
14:49:17 <daviddavis> it's quite a drastic change though because it would mean all FileFields would get cleaned up
14:49:24 <daviddavis> I think that's a good thing though?
14:49:50 <lmjachky> currently, we are not removing temporary files in the storage
14:50:11 <lmjachky> and any other files which are referenced via FileField
14:50:25 <lmjachky> after we call object.delete()
14:50:43 <lmjachky> django-cleanup handles this scenario and also deals with cascaded deletes
14:51:33 <lmjachky> I think everyone who once calls object.delete() wants to have deleted all referenced resources
14:51:54 <dkliban> i agree with that last statement lmjachky
14:52:01 <bmbouter> agreed
14:52:12 <daviddavis> so no objections to using django-cleanup ?
14:52:20 <dkliban> no objections from me
14:52:27 <daviddavis> it's a bit implicit was my only hesitation
14:52:34 <daviddavis> but also a bit expected
14:52:56 <ttereshc> the question is if there are any cases user does not expect it to be deleted
14:53:18 <ttereshc> dkliban, any scenarios for migration plugin which cleanup can break?
14:53:28 <lmjachky> once you delete a reference, you just have files in the storage that will eventually start to rot
14:53:41 <lmjachky> I am not sure if anyone would ever reach for those files
14:53:55 <daviddavis> it's possible to not have the file removed automatically by adding a decorator (@cleanup.ignore)
14:54:16 <dkliban> daviddavis: where do you put that decoraotr?
14:54:28 <daviddavis> https://github.com/un1t/django-cleanup#ignore-cleanup-for-a-specific-model
14:54:35 <lmjachky> from django_cleanup import cleanup
14:54:36 <lmjachky> @cleanup.ignore
14:54:36 <lmjachky> class MyModel(models.Model):
14:54:36 <lmjachky> image = models.FileField()
14:55:27 <dkliban> ttereshc: i don't think it's really a problem ... we create hard links for artifacts during migratin
14:55:57 <dkliban> if we delete the artifact for some reason and that hard link disappears also, the pulp 2 hardlink is sstill going to exist
14:56:14 <ttereshc> do we cover the case when a user uploads a file from the artifact storage? will it be removed?
14:56:19 <dalley> well, in theory https://pulp.plan.io/issues/7244
14:56:44 <lmjachky> uploads are already being removed
14:56:56 <dkliban> dalley: yeah ... if there are two separate drives, you can't hard links
14:57:40 <dkliban> dalley: maybeyour filesystem doesnt' support hard links
14:57:46 <dkliban> anyway, it doesnt' matter in this case
14:58:01 <dkliban> because you can still delete that file without affecting pulp 2
14:58:36 <dalley> dkliban, note, not my system, filed by Ian
14:59:13 <ttereshc> I think we can move on with the django cleanup
14:59:21 <dkliban> +1
14:59:28 <daviddavis> cool ok
14:59:29 <lmjachky> I am in favour of having django-cleanup used in pulpcore by default too; we may announce this change in pulp-dev and that is all
14:59:30 <ttereshc> especially because there is a way to ignore it
14:59:39 <daviddavis> +1
15:00:14 <ttereshc> should it be a part of Y release since it's a noticeable change?
15:00:26 <daviddavis> yes
15:00:53 <dkliban> yes for sure
15:00:55 <dkliban> 3.7
15:01:16 <daviddavis> I'll make a note on teh issue
15:01:24 <ttereshc> so maybe we should convert the issue into a task?
15:01:29 <ttereshc> yeah, or make a note, thanks
15:01:43 <dkliban> it's more of a plugin api feature
15:02:25 <daviddavis> it's both a bug fix and a plugin api feature
15:02:28 <fao89> daviddavis, I'm looking open floor hackmd, it seems you started a topic and did not finish
15:02:37 <daviddavis> sounds like me
15:02:48 <ttereshc> +1 to a plugin api chnagelog feature entry
15:02:49 <fao89> Is this ...
15:03:02 <lmjachky> https://www.youtube.com/watch?v=KpXsfimrkFo
15:03:09 <daviddavis> fao89: removed
15:03:53 <fao89> so, the next topic is: 3.7 tentative release date
15:05:08 <dkliban> bmbouter: did you have a proposal?
15:05:17 <bmbouter> I was just looking, I think the week after pulpcon
15:05:29 <bmbouter> so that would shoot for sept 25th
15:05:40 <bmbouter> it's time based so if it doesn't have all the things that's ok
15:06:18 <ttereshc> it's Friday
15:06:35 <daviddavis> !friday
15:06:35 <pulpbot> ♪ It's Friday, Friday, gotta get down on Friday ♪
15:06:36 <dkliban> we released on a thursday which was like a friday
15:06:42 <dkliban> and the world did not end
15:06:57 <bmbouter> oh whoops I was on the wrong month
15:06:59 <daviddavis> yea but whoever releases might not want to work late
15:07:06 <bmbouter> sept 22nd
15:07:09 <daviddavis> +1
15:07:10 <ttereshc> dkliban, so you are saying - let's continue that nice tradition? ;)
15:07:11 <dkliban> +!
15:07:18 <bmbouter> which when it slips 2 days we'll release on my bday the 24th
15:07:32 <ttereshc> :)
15:07:38 <dkliban> lol
15:08:18 <dkliban> bmbouter: and all the plugins will try to get RBAC done by then, but we expect only a subset to actually finish
15:08:19 <dkliban> right?
15:08:31 <bmbouter> yes
15:08:35 <dkliban> cool
15:08:40 <bmbouter> I don't expect plugins to finish by then really
15:08:55 <ttereshc> should we send the tentative date to pulp-dev?
15:08:56 <bmbouter> what I learned from ipanova|afk 's suggestion was that pulpcore and pulp_file would be rbac ready for 3.7
15:09:01 <bmbouter> ttereshc: yes we should
15:09:13 <bmbouter> and plugins can declare or not delcare their 3.7 releases as compat or not
15:09:13 <dkliban> yes we should
15:09:19 <bmbouter> s/compat/rbac compatible/
15:09:27 <bmbouter> I can send to pulp-dev if that's helpful
15:09:39 <dkliban> bmbouter: please do
15:09:48 <bmbouter> will do
15:09:54 <ttereshc> thanks
15:10:21 <fao89> topic: pulpcore 2-release backwards compatible policy?
15:10:55 <dkliban> so about 2.5 months ?
15:10:57 <bmbouter> so our users and us are both burdened by the "everything must release rush"
15:11:16 <bmbouter> it puts users in a bad spot hamstrung at every upgrade
15:11:26 <bmbouter> and we have to mad-release every month
15:12:02 <dkliban> bmbouter: this would introduce a lot more forking in our code
15:12:27 <dkliban> and for something like the openapi v3 change, i don't even know how we could have handled it
15:12:46 <dkliban> i don't think we could have
15:12:50 <bmbouter> I agree we could not have
15:13:28 <bmbouter> to be clear tho we're talking about the plugin API here
15:13:47 <x9c4> #info x9c4 has joined triage
15:13:47 <x9c4> !here
15:13:47 <pulpbot> x9c4: x9c4 has joined triage
15:13:49 <dkliban> this was a plugin api change that i am talking about
15:13:59 <bmbouter> I agree
15:14:14 <dkliban> bmbouter: we would need to increase our testing matrix
15:14:26 <dkliban> so that we are always testing changes against the last 2 releases of pulpcore
15:14:40 <x9c4> not necessarily.
15:15:00 <bmbouter> I was thinking it was more about forward compatability, plugins declare current_pulpcore+2 as max version
15:15:06 <x9c4> if you released a plugin today, it might be dependent on 3.6 features.
15:15:24 <x9c4> what ^^ said.
15:15:42 <x9c4> so pulpcore must maintain that compatibility for its plugins.
15:15:56 <bmbouter> the older thing to test is the older plugin aginst master
15:15:56 <x9c4> and that is still less than full semver.
15:15:59 <dkliban> bmbouter: but then pulpcore must be thouroughly tested with older plugins
15:16:09 <bmbouter> yup
15:16:18 <bmbouter> like as a nightly
15:16:28 <bmbouter> there is more testing to do here no disagreement on that
15:16:47 <dkliban> i completely see the value in this
15:16:52 <bmbouter> and also maybe now isn't the time to do this I've been contemplating this for a while
15:16:58 <bmbouter> but realistically when is?
15:17:13 <bmbouter> I don't see the feature demand or bugfix demand actually going down only up
15:17:20 <dkliban> i agree
15:18:09 <dkliban> i want to think about this some more
15:18:16 <dkliban> i am not ready to commit to this right now
15:18:27 <bmbouter> I agree, it's way to big of a thing to decide on the spot
15:18:44 <bmbouter> the main thing also isn't as much in the solution but the problem
15:19:07 <dkliban> i agree that we have a problem
15:19:08 <bmbouter> reflect on the problem statements and ask yourselves a) how much longer can we continue like this and b) what is the easiest way to resolve the problem statements
15:19:11 <dkliban> our users have a problem
15:19:35 <bmbouter> x9c4: and I have been talking this over some in PM so I wanted to bring it here
15:20:08 <x9c4> bmbouter++
15:20:08 <pulpbot> x9c4: bmbouter's karma is now 292
15:20:14 <dkliban> thank you
15:20:16 <dkliban> both
15:20:57 <x9c4> Testing aside, is it much to do? I think it is mainly as with the 0downtime a requirement on the future changes in pulpcore.
15:21:09 <dkliban> i agree
15:21:39 <daviddavis> I think it's a good idea. besides the recent schema change, I htink our plugin api has been pretty much stable in terms of backwards compatibility
15:21:49 <bmbouter> I agree there isn't much to slow the breaking changes in the plugin API over two releases
15:21:50 <dkliban> daviddavis: i agree
15:22:25 <bmbouter> and probably introduce the use of depcrecation warnings in the pulpcore.plugin that need to be removed at release 3.y
15:22:54 <x9c4> and the openapiv3 wasn't even a change to the plugin api. Yes the tests needed adjustments.
15:23:05 <bmbouter> x9c4: this was my point from earlier
15:23:15 <daviddavis> that's true
15:23:18 <bmbouter> it affected a lot of things but backwards incompatible in the plugin API it was not
15:23:33 <daviddavis> well no, there was some schema methods in views that had to be changed
15:23:39 <dkliban> yep
15:23:44 <bmbouter> a few things then
15:23:59 <dkliban> plugins had to make adjustments to support the new schema. so i would say that was a plugin api change
15:23:59 <bmbouter> I didn't actually do it so I don't know
15:24:00 <x9c4> right. But that fish is fried.
15:24:07 <dkliban> yes it is
15:24:10 <bmbouter> but we could have managed it
15:24:20 <bmbouter> the idea that we couldn't have managed it I don't think is accurate
15:24:49 <bmbouter> regardless it is fried
15:24:52 <dkliban> lol
15:25:22 <bmbouter> the tricky part is actually we can't ship both the old and new ones and so we can't maintain the deprecated parts in the plugin API ...
15:25:23 <x9c4> Well in retrospect, we would have needed to keep both schemas in parallel for one version.
15:25:29 <dkliban> bmbouter: i disagree with the statement that we could have generated both a v2 and a v3 schema if some plugins were using drf_yasg and others using drf-spectacular
15:25:31 <bmbouter> exactly, and we couldn't have
15:25:34 <dkliban> but it is fried
15:25:59 <daviddavis> in a beer batter with chips on the side
15:26:03 <dkliban> lol
15:26:14 <bmbouter> dkliban: yeah I think you're right because of the constraint of not being able to ship both
15:26:15 <dkliban> anyway, can we send this proposal to pulp-dev/
15:26:22 <dkliban> ?
15:26:37 <bmbouter> I can start the thread if folks don't mind me doing so before I'm out for a week
15:26:43 <bmbouter> or wait I'm ok for that also
15:26:49 <dkliban> let's not wait
15:27:06 <dkliban> it takes time to build concensus
15:28:14 <x9c4> +1
15:29:15 <bmbouter> I'll send it today
15:29:25 <ttereshc> This conversation reminded me about 2 topics, zero downtime migrations, and upgrade testing. Does anyone want those to be discussed at pulpcon? we don't have them among suggested topics.
15:30:25 <dkliban> ttereshc: we shoud;
15:30:29 <dkliban> should
15:30:36 <dkliban> discuss those at pulpcon
15:30:42 <x9c4> +1 for 0-downtime
15:30:55 <bmbouter> the issue with testing I think is that we don't have capacity
15:31:02 <bmbouter> I believe  we know the path
15:31:05 <bmbouter> remove orphan cleanup
15:31:11 <bmbouter> unique fixtures required for all tests
15:31:31 <ttereshc> yeah and it sounds it will never happen
15:31:45 <ttereshc> :)
15:31:54 <fao89> #endmeeting
15:31:54 <fao89> !end