15:34:49 <fao89_> #startmeeting Pulp Triage 2021-03-12
15:34:49 <fao89_> #info fao89_ has joined triage
15:34:49 <fao89_> !start
15:34:49 <pulpbot> Meeting started Fri Mar 12 15:34:49 2021 UTC.  The chair is fao89_. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:34:49 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:34:49 <pulpbot> The meeting name has been set to 'pulp_triage_2021-03-12'
15:34:50 <pulpbot> fao89_: fao89_ has joined triage
15:35:20 <fao89_> Open floor
15:35:23 <ggainey> #info ggainey has joined triage
15:35:23 <ggainey> !here
15:35:23 <pulpbot> ggainey: ggainey has joined triage
15:35:25 <ipanova> #info ipanova has joined triage
15:35:25 <ipanova> !here
15:35:25 <pulpbot> ipanova: ipanova has joined triage
15:36:14 <x9c4> #info x9c4 has joined triage
15:36:14 <x9c4> !here
15:36:14 <pulpbot> x9c4: x9c4 has joined triage
15:36:24 <ttereshc> #info ttereshc has joined triage
15:36:24 <ttereshc> !here
15:36:24 <pulpbot> ttereshc: ttereshc has joined triage
15:36:37 <dalley> #info dalley has joined triage
15:36:37 <dalley> !here
15:36:37 <pulpbot> dalley: dalley has joined triage
15:36:40 <fao89_> first topic: out CI is using ubuntu 20 now
15:36:46 * ggainey cheers wildly
15:36:59 <fao89_> if you see some weird error, it may be related
15:37:27 <fao89_> not the case for pulp-2to3-migration, ubuntu 20 was not guilty in this case
15:37:40 <fao89_> next topic: Plugin removal
15:37:49 <x9c4> I put that there.
15:38:29 <x9c4> I started to investigate whether a plugin can be removed by first unapplying all migrations and then removing the python bits.
15:38:46 <x9c4> There are two gaps until this can be used:
15:39:20 <x9c4> 1. migrations must be reversible (some plugins yes, some no)
15:40:08 <x9c4> 2. Removing a Detail model via a migration, does not delete the objects from the master table. This might be a django bug wrt inheritance.
15:41:05 <ggainey> hm, interesting.
15:41:37 <ggainey> we're not missing a CASCADE somewhere are we?
15:41:37 <x9c4> I think it is still worth making all migrations reversible even if we cannot solve 2. today.
15:41:47 <fao89_> +1
15:41:54 <x9c4> No, when you delete them trhough ORM it's fine.
15:42:17 <ggainey> how do we make migrations reversible - some things (deleting columns, trunc table, delete table) can't be undone
15:42:22 <ggainey> x9c4: ah ok
15:42:40 <x9c4> I tried this with a minimun django project and i've seen the same problem.
15:42:53 <ttereshc> it makes sense master-detail is controlled by orm
15:42:55 <x9c4> It's not related to anything special with our Master/Detail.
15:43:25 <ttereshc> ggainey, +1 on the concern about reversible migrations
15:43:34 <x9c4> reversing a migration, does not mean, that no data is lost on the way.
15:43:39 <fao89_> maybe a script bulk deleting with the orm would be a workaround
15:43:50 <x9c4> Adding columns is reversible by default in django
15:44:32 <x9c4> Adding models in the same way. The important thing is to transition the database from one consistent state to another.
15:44:37 <ggainey> because of the way django works, I 'assumed' delete-via-django is what we were doing - too much of the object-interrelationship in a django app, happens "inside django" only, you can't rely on going directly to the db
15:44:57 <ggainey> x9c4: what operations do we have to watch out for?
15:45:18 <x9c4> The non-reversible migrations are the ones calling PythonCode without providing a reverse_code.
15:45:35 <ttereshc> he problem for me is that when we claim that a migration is reversible, someone might try to downgrade, and that would mean that we need to bring data in a certain state as well
15:45:39 <x9c4> s/PythonCode/RunPython/
15:45:50 <ggainey> ah, ok
15:46:25 <ttereshc> if it was only used for plugin removal, it would be fine to just blindly mark all as reversible
15:46:26 <x9c4> reversing and then reapplying is a noop wrt the database scheme. Not wrt to the saved data.
15:48:40 <x9c4> > blindly mark all as reversible ; fine for me if it's still a consistent state
15:50:03 <x9c4> fao89_, If we could hook into the migration creation to do the bulk_delete that would make me more confident.
15:50:22 <ttereshc> could you define a consistent state?
15:50:50 <x9c4> a state where no serializer get's a hickup.
15:52:21 <ipanova> ttereshc: if we mark all migrations reversible for the sake of plugin removal we should document that so users don't expect they could downgrade then
15:52:33 <x9c4> how does django handle deleting a required field?
15:53:21 <ttereshc> ipanova, in such case, we do not need to worry about any consistent state, just revert and remove everything.
15:53:53 <ttereshc> if we do care about it being in some workable state, then I do not understand how we can workaround data being wrong potentially
15:54:36 <x9c4> you may be right there.
15:54:54 <ttereshc> x9c4, is it worth to start a hackmd doc or a pulp-dev thread (not usre if it's too early)
15:55:05 <ggainey> do we have plugin migrations that operate outside of the tables 'owned' by the plugin?
15:55:05 <ttereshc> we probably won't solve anything right now
15:55:13 <ggainey> ok yeah, that's fair
15:55:32 <x9c4> I'll start some info collection.
15:55:39 <ggainey> sounds like a fine plan
15:55:42 <ttereshc> that would be great
15:55:43 <ggainey> x9c4++
15:55:43 <pulpbot> ggainey: x9c4's karma is now 102
15:55:45 <x9c4> https://github.com/mdellweg/pulp_installer/blob/uninstall_plugins/docs/PLUGIN_UNINSTALLATION.md
15:55:48 <ttereshc> thanks for bringing this up
15:56:01 <x9c4> there are the steps in case anyone want's to experiment.
15:56:16 <ipanova> x9c4++
15:56:16 <pulpbot> ipanova: x9c4's karma is now 103
15:56:17 <ttereshc> x9c4, btw, we would need it relatively soon for a migration plugin
15:56:37 <ttereshc> (if we are not writing some custom workaround for it)
15:57:22 <x9c4> and for other plugins that fall out of maintenance.
15:57:38 <x9c4> ... and stop you from upgrading
15:57:54 <ggainey> yeah - but migration is a big one (both in usage, and an space-used, and in "I'm done with this remove all trace please" :) )
15:58:38 <ggainey> but, having it be easy to disconnect from the release-train of a plugin you don't use would be a great thing
15:59:41 <ttereshc> ggainey, x9c4, removal of a migration plugin is a katello ask, it was just not as urgent as other things
15:59:56 <ttereshc> that's why I said soon
16:00:03 <x9c4> +1
16:00:22 <ggainey> ttereshc: I'm just thinking about it from a user's POV - the migration-tables are pretty big, and once you've switched entirely to pulp3, they're just taking up space
16:00:24 <ggainey> yeah
16:00:46 <ttereshc> yup, that's exactly the reason
16:00:53 <ttereshc> shall we move to triage?
16:00:55 <fao89_> triage?
16:00:58 <ggainey> and by 'migration' we mean '2to3', not the general use of the word 'migration'
16:01:05 <ggainey> fao89_: yeah, works4me
16:01:10 <ttereshc> yup
16:01:12 <ttereshc> 2to3
16:01:22 <fao89_> !next
16:01:23 <pulpbot> fao89_: 7 issues left to triage: 8397, 8396, 8395, 8393, 8377, 8373, 8306
16:01:24 <fao89_> #topic https://pulp.plan.io/issues/8397
16:01:24 <pulpbot> RM 8397 - ipanova@redhat.com - POST - remove Addressing AccessPolicy via the viewset's classname
16:01:25 <pulpbot> https://pulp.plan.io/issues/8397
16:01:40 <ttereshc> #idea Proposed for #8397: Leave the issue as-is, accepting its current state.
16:01:40 <ttereshc> !propose accept
16:01:40 <pulpbot> ttereshc: Proposed for #8397: Leave the issue as-is, accepting its current state.
16:01:45 <fao89_> #agreed Leave the issue as-is, accepting its current state.
16:01:45 <fao89_> !accept
16:01:45 <pulpbot> fao89_: Current proposal accepted: Leave the issue as-is, accepting its current state.
16:01:46 <fao89_> #topic https://pulp.plan.io/issues/8396
16:01:46 <pulpbot> fao89_: 6 issues left to triage: 8396, 8395, 8393, 8377, 8373, 8306
16:01:47 <pulpbot> RM 8396 - ipanova@redhat.com - NEW - AttributeError: 'NoneType' object has no attribute 'get_host'
16:01:48 <pulpbot> https://pulp.plan.io/issues/8396
16:02:10 <ipanova> #idea Proposed for #8396: Leave the issue as-is, accepting its current state.
16:02:10 <ipanova> !propose accept
16:02:10 <pulpbot> ipanova: Proposed for #8396: Leave the issue as-is, accepting its current state.
16:02:26 <fao89_> #agreed Leave the issue as-is, accepting its current state.
16:02:26 <fao89_> !accept
16:02:26 <pulpbot> fao89_: Current proposal accepted: Leave the issue as-is, accepting its current state.
16:02:27 <fao89_> #topic https://pulp.plan.io/issues/8395
16:02:27 <pulpbot> fao89_: 5 issues left to triage: 8395, 8393, 8377, 8373, 8306
16:02:28 <pulpbot> RM 8395 - ipanova@redhat.com - POST - AttributeError: type object 'AccessPolicy' has no attribute 'NotFound'
16:02:29 <pulpbot> https://pulp.plan.io/issues/8395
16:02:55 <fao89_> #idea Proposed for #8395: accept and add to sprint
16:02:55 <fao89_> !propose other accept and add to sprint
16:02:55 <pulpbot> fao89_: Proposed for #8395: accept and add to sprint
16:02:55 <ttereshc> !propose accept
16:03:08 <ttereshc> +1
16:03:20 <fao89_> #agreed accept and add to sprint
16:03:20 <fao89_> !accept
16:03:20 <pulpbot> fao89_: Current proposal accepted: accept and add to sprint
16:03:21 <fao89_> #topic https://pulp.plan.io/issues/8393
16:03:21 <pulpbot> fao89_: 4 issues left to triage: 8393, 8377, 8373, 8306
16:03:22 <pulpbot> RM 8393 - jsherril@redhat.com - NEW - correlation id messages pollute log files
16:03:23 <pulpbot> https://pulp.plan.io/issues/8393
16:03:52 <ggainey> accept and add - easy to do, cutting down log-spam is good
16:04:02 <ttereshc> I thought there was a way to resolve it
16:04:02 <ggainey> I'd mark those msgs debug()
16:04:05 <fao89_> #idea Proposed for #8393: accept and add to sprint
16:04:05 <fao89_> !propose other accept and add to sprint
16:04:05 <pulpbot> fao89_: Proposed for #8393: accept and add to sprint
16:04:09 <ttereshc> we already brought it up in the past
16:04:11 <ipanova> i thought we have solved this
16:04:17 <ipanova> maybe in a later release
16:04:20 <x9c4> ithought it was solved too
16:04:25 <ggainey> huh, ok then :)
16:04:25 <ipanova> for some reason i think it was dalley
16:04:28 <ttereshc> ggainey, it's not us who logs it
16:04:32 <ggainey> ahhhhh
16:04:37 <fao89_> he mentions 3.9+
16:04:40 <dalley> we did
16:04:53 <dalley> yup, I patched it at one point
16:04:55 <x9c4> MAybe katello configures logging differently.
16:05:19 <dalley> https://github.com/pulp/pulpcore/pull/1057
16:06:01 <ggainey> let's point this issue/jsherill at this setting
16:06:05 <ttereshc> dalley, could you maybe point katello to it in the comments
16:06:11 <ggainey> heh, gmta
16:06:11 <ttereshc> and close as not a bug?
16:06:14 <ggainey> +1
16:06:31 <x9c4> Do we still want to mark them DEBUG?
16:06:52 <fao89_> I think we skip for now and close after talking with jsherill
16:06:53 <ggainey> I'm fine with them being what they are, as long as there's control over whether they come out or no
16:06:53 <ttereshc> x9c4, I think it's django-guid which logs them
16:07:02 <ggainey> yeah
16:07:36 <ttereshc> fao89_, we can
16:07:47 <x9c4> +1
16:07:52 <ipanova> +1
16:07:54 <ggainey> +1
16:07:56 <fao89_> !skip
16:07:56 <fao89_> #topic https://pulp.plan.io/issues/8377
16:07:58 <pulpbot> fao89_: 3 issues left to triage: 8377, 8373, 8306
16:07:59 <pulpbot> RM 8377 - fbachmann - NEW - Content Migration to Pulp 3 with Katello fails with message "No declared artifact"
16:08:00 <pulpbot> https://pulp.plan.io/issues/8377
16:08:13 <ggainey> ugh - accept and add, I'll look into centos8 (again)
16:08:14 <dalley> sounds familiar
16:08:25 <ggainey> yeah, it does, but I don't remember where exactly
16:08:34 <ttereshc> move to migrationplugin
16:08:40 <ggainey> oh yeah, that too :)
16:09:05 <fao89_> #idea Proposed for #8377: move to migration plugin accept and add to sprint
16:09:05 <fao89_> !propose other move to migration plugin accept and add to sprint
16:09:05 <pulpbot> fao89_: Proposed for #8377: move to migration plugin accept and add to sprint
16:09:08 <ttereshc> ggainey, I'm worried that it's relative path problem
16:09:09 <fao89_> #agreed move to migration plugin accept and add to sprint
16:09:09 <fao89_> !accept
16:09:09 <pulpbot> fao89_: Current proposal accepted: move to migration plugin accept and add to sprint
16:09:10 <fao89_> #topic https://pulp.plan.io/issues/8373
16:09:10 <pulpbot> fao89_: 2 issues left to triage: 8373, 8306
16:09:11 <pulpbot> RM 8373 - jsherril@redhat.com - NEW - backport 'Disable Dynaconf loading of .env files' to 3.7
16:09:12 <pulpbot> https://pulp.plan.io/issues/8373
16:09:23 <ggainey> ttereshc: /me cries, relatively
16:09:28 <ttereshc> lol
16:09:48 <ttereshc> accept and add to the sprint, I'll try to do it today
16:09:57 <x9c4> +1
16:09:59 <ggainey> kk
16:09:59 <fao89_> #idea Proposed for #8373: accept and add to sprint
16:09:59 <fao89_> !propose other accept and add to sprint
16:09:59 <pulpbot> fao89_: Proposed for #8373: accept and add to sprint
16:10:00 <ttereshc> the problem is that 3.7 branch is not using gha
16:10:10 <ttereshc> so I'd need some guidance from you fao89_
16:10:34 <fao89_> let's all pretend this issue never existed
16:10:38 <ggainey> hehehehe
16:10:39 <fao89_> hahaha
16:10:42 <ttereshc> :D
16:10:48 <x9c4> I've made that transition for container 2.1 this week, maybe i can help
16:10:58 <ggainey> +1
16:11:02 <ipanova> +1
16:11:06 <fao89_> #agreed accept and add to sprint
16:11:06 <fao89_> !accept
16:11:06 <pulpbot> fao89_: Current proposal accepted: accept and add to sprint
16:11:07 <fao89_> #topic https://pulp.plan.io/issues/8306
16:11:07 <pulpbot> fao89_: 1 issues left to triage: 8306
16:11:08 <pulpbot> RM 8306 - hyu - POST - Improve the speed of syncing repository
16:11:09 <pulpbot> https://pulp.plan.io/issues/8306
16:11:18 <ggainey> already in post - accept and add?
16:11:40 <ttereshc> x9c4, thank you
16:11:49 <fao89_> #idea Proposed for #8306: accept and add to sprint
16:11:49 <fao89_> !propose other accept and add to sprint
16:11:49 <pulpbot> fao89_: Proposed for #8306: accept and add to sprint
16:11:53 <ggainey> oh wait, 8306 is the pulp2 one
16:11:53 <ttereshc> I think we need to skip it
16:11:56 <dalley> ggainey, yeah
16:11:57 <ggainey> yeah
16:12:00 <dalley> skip
16:12:04 <fao89_> !skip
16:12:05 <pulpbot> fao89_: No issues to triage.
16:12:07 <ggainey> note to self: read first
16:12:08 <fao89_> !friday
16:12:08 <pulpbot> ♪ It's Friday, Friday, gotta get down on Friday ♪
16:12:10 <ggainey> !dance
16:12:10 <pulpbot> ♪┏(°.°)┛┗(°.°)┓┗(°.°)┛┏(°.°)┓ ♪
16:12:14 <fao89_> #endmeeting
16:12:14 <fao89_> !end