14:31:15 <fao89> #startmeeting Pulp Triage 2020-07-10
14:31:15 <fao89> !start
14:31:15 <fao89> #info fao89 has joined triage
14:31:15 <pulpbot> Meeting started Fri Jul 10 14:31:15 2020 UTC.  The chair is fao89. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:31:15 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:31:15 <pulpbot> The meeting name has been set to 'pulp_triage_2020-07-10'
14:31:15 <pulpbot> fao89: fao89 has joined triage
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:23 <ppicka> #info ppicka has joined triage
14:31:23 <ppicka> !here
14:31:23 <pulpbot> ppicka: ppicka has joined triage
14:31:39 <bmbouter> #info bmbouter has joined triage
14:31:39 <bmbouter> !here
14:31:39 <pulpbot> bmbouter: bmbouter has joined triage
14:31:41 <fao89> !next
14:31:42 <fao89> #topic https://pulp.plan.io/issues/7119
14:31:42 <pulpbot> fao89: 4 issues left to triage: 7119, 7110, 7109, 7105
14:31:43 <pulpbot> RM 7119 - osapryki - NEW - Tasks stay in waiting state if worker that had resource reservation gone
14:31:44 <pulpbot> https://pulp.plan.io/issues/7119
14:31:49 <x9c4> #info x9c4 has joined triage
14:31:49 <x9c4> !here
14:31:49 <pulpbot> x9c4: x9c4 has joined triage
14:32:05 <fao89> #idea Proposed for #7119: accept and add to sprint
14:32:05 <fao89> !propose other accept and add to sprint
14:32:05 <pulpbot> fao89: Proposed for #7119: accept and add to sprint
14:33:30 <bmbouter> and mark high prio
14:33:36 <bmbouter> high sev too I think
14:33:41 <daviddavis> +1
14:33:46 <bmbouter> it's important to us, and a user cannot recover when in this state
14:33:47 <ppicka> +1 to accept
14:33:50 <bmbouter> (assuming the report is accurate)
14:33:53 <fao89> #agreed accept and add to sprint
14:33:53 <fao89> !accept
14:33:53 <pulpbot> fao89: Current proposal accepted: accept and add to sprint
14:33:53 <fao89> #topic https://pulp.plan.io/issues/7110
14:33:54 <pulpbot> fao89: 3 issues left to triage: 7110, 7109, 7105
14:33:55 <pulpbot> RM 7110 - wibbit - NEW - pulpcore-client - Artifact upload fails when using python27
14:33:56 <pulpbot> https://pulp.plan.io/issues/7110
14:34:56 <daviddavis> question: do we support python 2 for our bindings?
14:35:44 <dalley> is that a "do we currently" or a "should we"?
14:35:50 <dkliban> #info dkliban has joined triage
14:35:50 <dkliban> !here
14:35:50 <pulpbot> dkliban: dkliban has joined triage
14:36:12 <bmbouter> we should not it is EOL
14:36:19 <x9c4> I think, we do.
14:36:21 <fao89> I remember it uses six
14:36:21 <dkliban> i propose that we not support python 2.7
14:36:32 <dkliban> we should drop support for it
14:36:46 <daviddavis> +1 from me
14:36:51 <dkliban> i know that the templates for openapigenerator try to support it
14:36:53 <ppicka> +1 to not support py2
14:36:54 <dalley> also 7119 is a duplicate of the issue I currently have a PR open for bmbouter
14:37:03 <dkliban> i agree dalley
14:37:05 <fao89> actually, bindings are totally a black box
14:37:21 <fao89> I'm more convinced we should have repos for it
14:38:20 <dkliban> fao89: let's discuss at open floor
14:38:27 <fao89> what should be the action for this issue?
14:38:40 <dkliban> let's skip for now
14:38:47 <fao89> !skip
14:38:48 <fao89> #topic https://pulp.plan.io/issues/7109
14:38:48 <dkliban> and we will talk about it at open floor
14:38:48 <pulpbot> fao89: 2 issues left to triage: 7109, 7105
14:38:49 <pulpbot> RM 7109 - kossusukka - NEW - Changing MEDIA_ROOT does not propagate to STATIC_ROOT etc
14:38:50 <pulpbot> https://pulp.plan.io/issues/7109
14:39:12 <daviddavis> I think this is expected
14:39:39 <bmbouter> dalley: let's talk more about that after this
14:39:40 <daviddavis> we should probably update our settings.py to not reuse MEDIA_ROOT because it creates a false impression
14:40:01 <bmbouter> daviddavis: I agree separating them would be better
14:40:01 <fao89> accept?
14:40:56 <fao89> #idea Proposed for #7109: Leave the issue as-is, accepting its current state.
14:40:56 <fao89> !propose accept
14:40:56 <pulpbot> fao89: Proposed for #7109: Leave the issue as-is, accepting its current state.
14:41:05 <daviddavis> sure, I can leave a note
14:41:26 <fao89> #agreed Leave the issue as-is, accepting its current state.
14:41:26 <fao89> !accept
14:41:26 <pulpbot> fao89: Current proposal accepted: Leave the issue as-is, accepting its current state.
14:41:27 <pulpbot> fao89: 1 issues left to triage: 7105
14:41:28 <fao89> #topic https://pulp.plan.io/issues/7105
14:41:28 <pulpbot> RM 7105 - iballou - NEW - Applicability misreporting as [] for exactly one EL7 consumer
14:41:29 <pulpbot> https://pulp.plan.io/issues/7105
14:41:54 <fao89> #idea Proposed for #7105: move to rpm
14:41:54 <fao89> !propose other move to rpm
14:41:54 <pulpbot> fao89: Proposed for #7105: move to rpm
14:44:00 <daviddavis> the last fix for this was actually in pulp
14:44:16 <daviddavis> https://pulp.plan.io/issues/6724
14:44:34 <daviddavis> but perhaps investigation needs to happen in pulp_rpm first
14:44:42 <fao89> #agreed move to rpm
14:44:42 <fao89> !accept
14:44:42 <pulpbot> fao89: Current proposal accepted: move to rpm
14:44:43 <pulpbot> fao89: No issues to triage.
14:44:53 <daviddavis> I'm not super familiar with applicability tho
14:44:58 <daviddavis> so don't listen to me :P
14:45:05 <fao89> open floor - https://hackmd.io/SVCMjpwXTfOMqF2OeyyLRw
14:45:17 <fao89> topic: zero down time upgrades
14:45:49 <bmbouter> I put this on here, it came from the installer meeting
14:46:38 <bmbouter> my goals here are to bring some awareness to this need, answer questions, and then bring the discussion to pulp-dev
14:46:54 <fao89> I think it would help mikedep333 with the pre-flight
14:47:14 <bmbouter> agreed, and also a better experience for users overall, and also for the operator I think it's a requirement actually
14:47:28 <dkliban> yes, it is a requirement with the operator
14:47:55 <fao89> plugins dependency hell is the installer weakest point
14:48:38 <x9c4> I think we said this is not a _thing_ we can do, but a strict policy we need for all db migrations that are to come in the future. Hence awareness is key.
14:48:43 <dkliban> and not only with the operator, but any deployment where the deployment is split up accross multiple servers
14:49:08 <dkliban> x9c4: that's right
14:49:30 <bmbouter> yeah the goal here is a policy really x9c4 as you say
14:49:39 <bmbouter> and to document that policy in the plugin writer notes
14:50:22 <bmbouter> so if there aren't questions here about why or how, then the next step would be for someone (I can) to write up the documentation issue and then advertise it on pulp-dev
14:51:13 <dkliban> i think there will be questions once you write something up
14:51:23 <dkliban> or when ttereshc is back
14:51:25 <fao89> as we are talking about db migrations, I bet Tanya would like to discuss it
14:51:32 <dkliban> :)
14:51:56 <bmbouter> I hope so this is too significant to have 0 questions
14:52:21 <bmbouter> ok I can write up the issue then and bring it back at next week's open floor for more discussion?
14:52:23 <x9c4> Seems like there is no question that we want to have it.
14:52:24 <dkliban> bmbouter: let's take the next step
14:52:33 <dkliban> exactly x9c4
14:52:34 <bmbouter> also I'll advertsie to pulp-dev
14:52:42 <fao89> this open floor is being installers meeting
14:52:44 <dkliban> bmbouter: sounds good
14:52:49 <bmbouter> will do ty all
14:53:18 <fao89> next:Retry fix https://github.com/pulp/nectar/pull/67/
14:53:45 <dkliban> it makes sense to me
14:53:54 <dkliban> i'll review it
14:53:58 <daviddavis> dkliban++
14:53:58 <pulpbot> daviddavis: dkliban's karma is now 492
14:54:17 <dkliban> and i'll make sure that the build team builds a new version of this
14:54:27 <dkliban> of nectar so it can go out with the new beta
14:54:37 <bmbouter> it also makes sense to me
14:54:40 <bmbouter> I looked at this this morning
14:54:44 <bmbouter> but +1 to your review dkliban
14:54:53 <daviddavis> my only concern was its impact to Pulp 2
14:55:12 <daviddavis> I'm not familiar with nectar but I know it's used by every Pulp 2 plugin
14:55:20 <dkliban> yep
14:55:35 <daviddavis> but several users/customers are stuck and this would help them out I believe
14:55:48 <dkliban> daviddavis: the impact is that pulp 2 will be better
14:55:54 <daviddavis> haha good :)
14:56:05 <dkliban> daviddavis: right now we have pulp 2 making 20 threads to perform downloads
14:56:25 <dkliban> or some number
14:56:31 <dkliban> i don't remember the exact tuning
14:56:40 <dkliban> but the problem is that they share the number of retries
14:56:49 <daviddavis> I see
14:57:02 <dkliban> so at some point one of them has 0 retries left because other threads used them up
14:57:40 <bmbouter> it's 5 AIUI
14:57:52 <dkliban> cool
14:57:56 <bmbouter> really though it shouldn't even be per thread it should be per item...
14:58:01 <dkliban> yep
14:58:06 <daviddavis> yea
14:58:08 <bmbouter> that's how it works w/ pulp3 at least
14:58:12 <dkliban> and i think that's what this patch will do
14:58:57 <bmbouter> I think you're right but the commenton the PR suggests otherwise
14:59:50 <dkliban> i'll comment on the PR with a question about it
14:59:54 <daviddavis> dkliban: you may want to suggest he squashes these commits too
15:00:34 <dkliban> hmm
15:00:36 <dkliban> actually
15:00:39 <dkliban> i now see the second commit
15:00:40 <bmbouter> actually it's per thread like the comment says
15:00:54 <bmbouter> otherwise this wouldn't be reusing the same session in this line https://github.com/pulp/nectar/pull/67/files#diff-609b5250f930300d62fd3da027ef9608R272
15:01:11 <bmbouter> it instead wold be calling session = self._make_session() and then using that session
15:01:15 <bmbouter> (a new session per request)
15:01:23 <bmbouter> but still this does make it better...
15:01:51 <bmbouter> and perhaps a new session per request would create side effects I don't understand atm
15:02:08 <daviddavis> that was my concern
15:02:29 <bmbouter> so these are requests.Sessions https://2.python-requests.org/en/master/user/advanced/
15:02:33 <dkliban> the first commit is actually reverted in the second commit
15:02:38 <daviddavis> yup
15:02:41 <dkliban> so i am not concerned now
15:02:47 <bmbouter> aaand if we isolate them we won't receive connection reuse per their docs
15:02:59 <dkliban> cool
15:03:02 <bmbouter> which is also like pulp3 haha
15:03:34 <bmbouter> so overall i'm +1 to accept a squashed version of this patch
15:03:44 <daviddavis> cool
15:04:15 <dkliban> i left a review https://github.com/pulp/nectar/pull/67#pullrequestreview-446476410
15:05:10 <dkliban> we are ready for our next topic
15:05:18 <bmbouter> ack
15:05:26 <fao89> topic: MODIFIED issues. Can these be closed out?
15:05:54 <fao89> issues from no release projects (plugin_template, ...)
15:05:55 <dkliban> 6750 -= yes
15:06:18 <daviddavis> done
15:06:23 <dkliban> 6768 - yes
15:06:28 <daviddavis> done
15:06:44 <dkliban> 6713  yea
15:06:44 <x9c4> 6713 -yes
15:06:57 <daviddavis> done
15:06:58 <x9c4> 6834 - yes
15:07:19 <dkliban> 6899 yes
15:07:19 <daviddavis> done
15:07:21 <bmbouter> yes
15:07:28 <dkliban> awesome
15:07:36 <fao89> topic: bindings - too magical (where is the code? where are the docs?)
15:07:40 <daviddavis> ty
15:07:54 * daviddavis casts a binding spell
15:08:10 <dkliban> Even if we don't publish the code, we should at least have a repository that contains the docs that are generated
15:08:25 * x9c4 hopes on openapiv3
15:08:39 <dkliban> x9c4: what's the hope?
15:08:40 <daviddavis> could we publish the bindings docs?
15:09:00 <dkliban> daviddavis: we need to desperately, but we don't have a good place to publish them
15:09:05 <daviddavis> ah
15:09:05 <fao89> I had problem with mixed formats rst x md
15:09:09 <x9c4> Hope that it can be used on the fly without generated bindings.
15:09:12 <daviddavis> o right
15:09:22 <bmbouter> also I have concerns about us checking in large amounts of auto-generated docs
15:09:35 <bmbouter> you generally don't check in built assets back to source control
15:10:03 <bmbouter> so publishing them somewhere would solve that problem
15:10:05 <fao89> but going back to python2 discussion, we will have to modify the bindings to accomplish it
15:10:18 <bmbouter> python2 is EOL so I think we don't need to support it
15:10:22 <dkliban> fao89: accomplish what?
15:10:34 <fao89> dropping python2 support
15:10:47 <daviddavis> what if we just document that we don't support it?
15:10:50 <dkliban> fao89: i think we just need to add documentation that we don't support it
15:11:02 <dkliban> even though there is code thatmakes it seem like we do
15:11:11 <daviddavis> maybe on https://docs.pulpproject.org/client_bindings.html
15:11:13 <bmbouter> I don't think we even need to do that python2 dropped support for itself
15:11:22 <x9c4> fwiw pulp/squeezer uses the bindings with python2 and there was never a problem.
15:11:22 <dkliban> lol
15:11:36 <dkliban> x9c4: does it use the upload api?
15:11:39 <daviddavis> x9c4: did you try file uploads
15:11:50 <x9c4> It creates artifacts
15:12:09 <fao89> I think we need to handle it at pypi level, it should not be installable on python2
15:12:10 <x9c4> so chunked upload.
15:12:14 <daviddavis> interesting
15:12:21 <dkliban> fao89: we can make that happen
15:12:23 <daviddavis> not sure why they're seeing something different in https://pulp.plan.io/issues/7110
15:12:44 <dkliban> fao89: it's pretty easy to do with a custom setup.py
15:13:31 <dkliban> is everyone ok with us adjusting the setup.py for the python bindings to not support python 3?
15:13:47 <daviddavis> no
15:13:52 <daviddavis> we def want python 3
15:13:55 <dkliban> oooops
15:13:58 <dkliban> python 2
15:13:59 <bmbouter> lol
15:14:00 <daviddavis> +1
15:14:03 <bmbouter> +1
15:14:06 <dkliban> daviddavis: than you
15:14:12 <dkliban> i'll comment on this issue
15:14:32 <dkliban> stating that we will be dropping support for python 2
15:14:39 <dkliban> and i'll also provide a plan for how to do it
15:15:14 <bmbouter> excellentay
15:15:27 <fao89> back to docs, how can we handle it?
15:15:57 <bmbouter> so I think it's time we explore making docs.pulpproject.org better
15:16:02 <fao89> I tried to make sphinx accept md, but it was too ugly
15:16:07 <dkliban> bmbouter: i was thinking that every time we publish a new version of the bindings we would create a new branch in the bindings git repo and commit those docs to that branch
15:16:08 <bmbouter> and this is a practical focused way to do that
15:16:18 <bmbouter> that still puts them into source control
15:16:21 <bmbouter> which is what I'm looking to avoid
15:16:23 <fao89> I tried to convert md to rst, but it didn't go well
15:16:25 <bmbouter> as a general practice
15:16:41 <dkliban> bmbouter: that's cool and i think it's a fine goal
15:17:03 <dkliban> however, there are security implications for allowing plugins outside our control to publish to docs.pulpporject.org
15:17:07 <bmbouter> so how about we integrate them to publish "into" docs.pulpproject.org
15:17:38 <bmbouter> I think we could security restrict the rsync commands to chroot them to a subdir
15:17:50 <bmbouter> duck knows how to do this
15:18:20 <dkliban> if the team that manages taht infra has no concerns, then i am fine with it
15:18:28 <daviddavis> +1
15:18:36 <fao89> I think mkdocs has a build option which generates the static files
15:18:43 <fao89> https://www.mkdocs.org/user-guide/deploying-your-docs/
15:18:45 <bmbouter> mkdocs is the jammy jam
15:18:45 <dkliban> fao89: that would be great
15:19:19 <fao89> I can try a PoC with mkdocs
15:19:45 <bmbouter> fao89: that sounds great, we also need an issue that identifies the dir they will push into on docs.pulpproject.org
15:19:53 <bmbouter> or some discussion here, either way
15:20:05 <dkliban> bmbouter: so let's reach out to duck and see about adding a new user for rsyncing plugin docs. i want this to be practice for creating othter users that will be used for plugins that we don't control
15:20:45 <bmbouter> yup
15:20:45 <fao89> "duck knows how to do this" - I thought this was a slang
15:20:51 <bmbouter> hahaha
15:20:54 <dkliban> duck is a person
15:20:56 <bmbouter> this persons nick name is duck
15:20:59 <bmbouter> no joke
15:21:01 <bmbouter> lol
15:21:03 <dkliban> yep
15:21:10 <bmbouter> he even quacks as a hello it's great
15:21:18 <fao89> hahaha
15:21:21 <bmbouter> he's our infra spirit animal
15:21:39 <dkliban> this will greatly improve the user experience of the bindings
15:21:42 <bmbouter> I agree
15:22:01 <bmbouter> we need this plan written some before we start doing things I think
15:22:02 <fao89> I just did mkdocs build at pulp_installer and it indeed creates a dir with static files
15:22:13 <bmbouter> that part sounds great
15:22:13 <dkliban> bmbouter: i can write a ticket
15:22:31 <bmbouter> dkliban: that would be great I can collab on it if you start and send it to me
15:22:42 <dkliban> bmbouter: sounds good. i'll do it this afternoon
15:23:05 <bmbouter> great ty
15:23:27 <fao89> next topic: release automation – what’s next?
15:24:36 <bmbouter> I put this one there ... what's next?
15:25:19 <dkliban> release pipeline
15:25:52 <dkliban> we need to create teh pulpcore-packaging repository
15:25:57 <dkliban> we have a task for this
15:26:10 <dkliban> and then we need to start moving the automation into this repository
15:26:21 <daviddavis> woudl it help to meet next week to start the design for this?
15:26:28 <dkliban> so that the next time we release we can release pulpcore, pulp_file and pulp_installer at the same time
15:27:05 <dkliban> daviddavis: yes, i was hoping we could dedicate our CI meeting to this planning
15:27:10 <daviddavis> +1 from me
15:27:50 <fao89> I was under impression it would be dropped for the next 3 months
15:28:07 <daviddavis> ok, let's drop it and add a unified release pipeline meeting
15:28:09 <daviddavis> same time
15:28:14 <dkliban> lol
15:28:31 <dkliban> i'll try to keep this meeting short by bringing a plan to the meeting
15:28:35 <daviddavis> great
15:28:39 <dkliban> so we have something concrete to discuss right away
15:28:51 <daviddavis> we can make it nonrecurring too
15:28:55 <dkliban> so that's the goal bmbouter: release pulpcore, pulp_file, and pulp_installer using the pulpcore-packaging CI
15:28:58 <fao89> yep
15:29:14 <fao89> I think weekly is too much
15:29:19 <dkliban> fao89: i agree
15:29:31 <dkliban> we can do the CI failure checkin in this channel
15:29:36 <bmbouter> so I was wondeirng is: is there a way to shorten the release time investment
15:29:52 <dkliban> bmbouter: did you have any ideas?
15:29:54 <fao89> sounds good
15:29:57 <bmbouter> for example we release pulpcore every 4ish weeks, then 7-8 plugins have to release after it over 3 months that's like 24 releases
15:30:14 <bmbouter> what about the extra steps you and daviddavis talked about this morning?
15:30:22 <bmbouter> the bumping and branching?
15:30:48 <dkliban> we could add automation for that also
15:30:48 <bmbouter> or what about a script that calls it on 3 repos instead of doing all 3 independantly?
15:31:10 <bmbouter> we should try to do more incremental improvmements for it because it will give us back any time invested
15:31:12 <bmbouter> I gotta run
15:31:28 <daviddavis> me too. I can bring this up at the ci/cd meeting on wednesday
15:31:44 <dkliban> we can do some emailing about this before then
15:32:02 <dkliban> i think we should end the meeting now because we are at our time
15:32:10 <fao89> #endmeeting
15:32:10 <fao89> !end