14:31:50 #startmeeting Pulp Triage 2020-07-24 14:31:50 !start 14:31:50 #info fao89 has joined triage 14:31:50 Meeting started Fri Jul 24 14:31:50 2020 UTC. The chair is fao89. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:31:50 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:31:50 The meeting name has been set to 'pulp_triage_2020-07-24' 14:31:50 fao89: fao89 has joined triage 14:31:55 #info ggainey has joined triage 14:31:55 !here 14:31:55 ggainey: ggainey has joined triage 14:32:20 #info ipanova has joined triage 14:32:20 !here 14:32:20 ipanova: ipanova has joined triage 14:32:27 #info ttereshc has joined triage 14:32:27 !here 14:32:27 ttereshc: ttereshc has joined triage 14:32:33 !next 14:32:34 #topic https://pulp.plan.io/issues/7209 14:32:34 fao89: 5 issues left to triage: 7209, 7205, 7196, 7185, 7178 14:32:35 RM 7209 - dkliban@redhat.com - NEW - OpenAPI schema paths are not namespaced 14:32:36 https://pulp.plan.io/issues/7209 14:32:38 !here 14:32:38 #info bmbouter has joined triage 14:32:38 #info dalley has joined triage 14:32:38 !here 14:32:38 bmbouter: bmbouter has joined triage 14:32:39 dalley: dalley has joined triage 14:32:50 #info x9c4 has joined triage 14:32:50 !here 14:32:50 x9c4: x9c4 has joined triage 14:33:36 !poropose accept 14:33:36 ipanova: Error: "poropose" is not a valid command. 14:33:41 #idea Proposed for #7209: accept and add to sprint 14:33:41 !propose other accept and add to sprint 14:33:41 fao89: Proposed for #7209: accept and add to sprint 14:33:46 +1 14:33:52 +1 14:33:53 +1 14:34:00 #agreed accept and add to sprint 14:34:00 !accept 14:34:00 fao89: Current proposal accepted: accept and add to sprint 14:34:01 #topic https://pulp.plan.io/issues/7205 14:34:01 fao89: 4 issues left to triage: 7205, 7196, 7185, 7178 14:34:02 RM 7205 - pc - NEW - ClientConnectorSSLError during remote sync with cdn.redhat.com 14:34:03 https://pulp.plan.io/issues/7205 14:34:24 #info dkliban has joined triage 14:34:24 !here 14:34:24 dkliban: dkliban has joined triage 14:35:11 could this be throttling also? 14:35:43 'unexpected alert' is odd 14:35:48 perhaps .... 14:36:14 we can skp for now (we have no reproducer) and I can comment asking him to try the download_concurrency, wdyt? 14:36:48 yeah ... we can ask to change the download_concurrency 14:36:56 but it does seem like there is a reproducer 14:37:05 maybe - but that's usually a bad-ssl-handshake issue, not a "far end told us to go away" message 14:37:19 they mentioned using "high-concurrency aira2c download of repo contents" which worked for them 14:37:49 I wonder if there is other issue than throttling 14:37:52 "iptraf-ng's IP Traffic Monitor shows much higher number of lingering connections for Pulp than wget or aria2c." 14:38:15 maybe we can ask for specific numbers 14:38:19 yeah 14:38:24 can it be some cdn temporary hiccup? 14:38:27 let's ask for specific numbers about the connections 14:38:35 ipanova: it could be 14:38:36 if the server isn't replying I suspect it's the 20 parallel connection waiting 14:38:46 I applied this comment already FWIW https://pulp.plan.io/issues/7205#note-1 14:38:57 sounds good 14:39:14 thanks 14:39:20 let's skip for now 14:39:25 agree 14:39:32 #info daviddavis has joined triage 14:39:32 !here 14:39:33 daviddavis: daviddavis has joined triage 14:39:54 #idea Proposed for #7205: Skip this issue for this triage session. 14:39:54 !propose skip 14:39:54 daviddavis: Proposed for #7205: Skip this issue for this triage session. 14:39:54 !skip 14:39:55 #topic https://pulp.plan.io/issues/7196 14:39:56 fao89: 3 issues left to triage: 7196, 7185, 7178 14:39:57 RM 7196 - alikins - NEW - pulpcore.app.response.OperationPostponedResponse docstring is slightly wrong (no 'task' field in response) 14:39:58 https://pulp.plan.io/issues/7196 14:40:10 accept and add to sprint? 14:40:12 +1 14:40:15 #idea Proposed for #7196: accept and add to sprint 14:40:15 !propose other accept and add to sprint 14:40:15 fao89: Proposed for #7196: accept and add to sprint 14:40:19 +1 14:40:21 #agreed accept and add to sprint 14:40:21 !accept 14:40:21 fao89: Current proposal accepted: accept and add to sprint 14:40:22 #topic https://pulp.plan.io/issues/7185 14:40:22 fao89: 2 issues left to triage: 7185, 7178 14:40:23 RM 7185 - yuzheng - NEW - force_full rsync publish is done unnecessarily in some cases 14:40:24 https://pulp.plan.io/issues/7185 14:40:24 +1 14:40:43 let's skip this for now 14:40:50 +! 14:40:50 +1 14:40:57 !skip 14:40:58 #topic https://pulp.plan.io/issues/7178 14:40:58 fao89: 1 issues left to triage: 7178 14:40:59 RM 7178 - ekohl - POST - Recommended installation layout 14:41:00 https://pulp.plan.io/issues/7178 14:42:32 it seems that the conversation is ongoing 14:42:50 should we skip again until there is any agreement on the ticket? 14:42:57 yes please 14:42:59 it is ongoing 14:42:59 +1 14:43:01 !skip 14:43:02 fao89: No issues to triage. 14:43:13 Open floor - https://hackmd.io/SVCMjpwXTfOMqF2OeyyLRw 14:43:24 topic: Should we delete alpha versions of released pulp packages from pypi? 14:43:34 yes 14:43:45 yes 14:43:52 +1 14:44:00 +1 14:44:00 +1 14:44:06 I can do this today unless someone else wants to 14:44:26 just alpha and not rc/betas right? 14:44:33 +1 14:44:37 we will get to those later 14:44:40 as more time passes 14:45:05 what about these dev releases? 14:45:14 alpha dev releases? 14:45:31 some .dev's are also our nightlies I think 14:45:32 eg https://pypi.org/manage/project/pulp-file-client/release/1.2.0.dev1595590377/ 14:45:37 ah ok 14:45:51 ah these are our bidnings 14:46:09 Do we still need to publish those nightly? 14:46:34 I think we do 14:46:40 it's the CD in our CI/CD 14:46:49 we could delete some of the old one sthough 14:46:56 it's a lot of packages out there 14:47:23 wouldn't it be sufficient to only publish the versions matching a release we also publish? 14:47:40 it would for end users but some folks want to do pre-release testing 14:47:47 it's so that the master branches can have a client out there 14:47:52 katello 14:47:57 = some folks 14:48:04 ok. 14:48:31 wait 14:48:43 what about if we only publish them when there are changes to master 14:48:47 or are we already doing that 14:48:55 no we are not 14:49:08 i think we are using a timestamp and not a sha 14:49:11 yup 14:49:14 we publish every day 14:49:21 I know it's a lot of released but I don't think that's a bad thing 14:49:26 computers are storing it and they don't care 14:49:45 that's fine 14:50:22 actually 14:50:34 trying to find a client for a particular release is hard: https://pypi.org/project/pulp-file-client/#history 14:50:40 where's the bindings for 1.1.0? 14:50:52 or 1.0.0 14:51:11 I don't think we have to address this now but maybe sometime in the future 14:51:22 pip can tell pre-releases from non pre-releases even if that UI can't 14:51:56 I hear what you're saying but helping that problem makes other things more difficult (like spotting problems in machinery that publishes intermittently) 14:52:13 that list is crazy long tho so this is a problem 14:52:51 it's not a now problem though 14:52:56 anyway, we can continue 14:53:31 have too many releases weakens the "notification of release" feature https://pypi.org/help/#project-release-notifications 14:53:42 to your point daviddavis 14:53:47 +1 we can continue 14:55:13 maybe we bored fao89 to sleep 14:55:38 I was confused if continue means continue the discussion, hahaha 14:55:45 topic: * Can we configure modified as a closed state in redmine? 14:55:46 ah ha sorry 14:56:00 is it possible in redmine? 14:56:00 now I get it is continue the open floor 14:56:04 it is 14:56:05 yes it's possible 14:56:14 we would set it in one place, here https://pulp.plan.io/issue_statuses/4/edit 14:56:27 Is it breaking any other integration? 14:56:47 it's possible but I don't know that it would 14:57:06 i am in favour of making this change otherwise we are always tight to a release which might now happen for some time 14:57:08 if it did it would be because a saved query was relying on its state and when we learned it was broken we could update that saved query to match 14:57:15 might not happen* 14:57:29 I'm also +1 on it, at least trying it 14:57:35 +1 from me 14:57:36 yeah concur 14:58:00 next topic? 14:58:06 We could rename it to Closed- Nextrelease... 14:58:54 the names mirror the names in other system s like bugzilla 14:59:00 and our docs 14:59:15 who is clicking this button, is it meeeee ? 14:59:24 heh 14:59:26 +1 14:59:30 does that mean we can also blame you when stuff breaks? 14:59:41 yes 14:59:45 even though this was a group decision 14:59:47 also for things I haven't done yet 14:59:51 or things I may do in the future 14:59:55 sounds good 15:00:02 * bmbouter gives thumbs up 15:00:05 lol 15:00:07 * bmbouter clicks button with thumbs 15:00:15 "my lab teacher in college taught us Always work in groups. It makes it impossible to assign blame when things go worng." 15:00:21 :) 15:01:19 clicked 15:01:25 * ggainey cheers wildly 15:01:35 ready for next topic? 15:01:38 * x9c4 thinks peer review is a kind of working in a group. 15:01:50 +1 next topic 15:01:54 +1 15:02:03 topic: What do you all think about renaming master-branches to develop? 15:02:24 I absolutely support the effort. I suggest we delay until post-October 15:02:35 given the load everyone is already carrying 15:02:38 that makes sense. stuff is going to break. 15:02:45 yeah that was my thought 15:02:58 pick a week in November and just bite the bullet 15:02:59 agreed all around 15:03:04 yes, let's postpone 15:03:31 +1 15:03:39 sounds good 15:03:46 topic: Adjusting download concurrency -- needs a bit of testing first 15:03:58 https://pulp.plan.io/issues/7212 15:05:07 so this is asking to sync-immediate, say, CentOS7 with the various values for concurrency and record wall-time? 15:05:17 or are we looking for detailed perf-analysis? 15:05:37 the former, just a wall-clock-time of each concurrency level 15:05:41 ok, cool 15:05:47 makes sense 15:05:55 if someone really wants to go the distance do an average of 3 runs 15:05:56 I've been syncing centos and rhel for PIE testing - I can take this this sprint 15:06:17 that would be way cool, then can you bring it back to open floor for a final decisions 15:06:29 ok, can do - I'll update the issue 15:06:29 and dalley I want to hear what you think is right once we hear the numbers also 15:06:33 ggainey: ty! 15:06:37 np 15:06:44 ggainey++ 15:06:44 daviddavis: ggainey's karma is now 33 15:07:03 ggainey++ 15:07:03 x9c4: ggainey's karma is now 34 15:07:05 cool, I'm good w/ that 15:07:50 it's something I can run on the weekend, since it will be 99% waiting 15:08:01 while you watch tiger king 15:08:07 zacly! rawr! 15:08:43 I want to join ggainey and daviddavis meetings 15:09:01 * fao89 cheers wildly 15:09:03 hehehe 15:09:09 :) 15:09:43 next topic: RBAC: permission creation solution FYI - https://pulp.plan.io/issues/7210 15:10:53 so galaxy_ng has use cases motivating this as requirements 15:11:10 and as I considered their needs I see pulp users having the same 15:11:37 yep 15:11:54 we give users all this control to customize rbac and if permission assignment can't be configured to match that then all that other customization won't matter due to permissions not being there on new objects 15:12:11 that makes sense 15:12:15 so I plan to put this together into my RBAC PR I believe it's straightforward 15:12:27 ahhh, kk, I think I grok this 15:12:29 also this was one of the called out problems back on our slide demo but there wasn't a design then 15:12:30 so will this be accessible via rest api? django admin? 15:12:44 some rest API endpoint as the policy statements itself 15:12:55 I need to clarify that on the ticket actually 15:13:04 yeah .. that part is not clear to me 15:13:34 it's not written :/ so the AccessPolicySerializer will have `statements`, and `permission_assignment` 15:14:29 aside: the pulp_container roadmap did get a lot more meaningful https://pulp.plan.io/projects/pulp_container/roadmap 15:14:45 nice! 15:14:56 \me cheers like crazy 15:15:00 I'd like to put this story on the sprint 15:15:06 b/c I'm working on it today 15:15:17 heh - then by definition it's on the sprint :) 15:15:56 pretty much 15:16:07 go4it, sez I 15:16:45 this will also be included in an update email to pulp-dev today 15:16:48 along w/ other RBAC updates 15:16:56 niice 15:17:26 awesome 15:18:08 groovy 15:18:19 ack: I will add in the `permission_assignment` parts and add to sprint 15:18:22 I'm doing that now 15:18:29 coolio 15:19:03 last topic: Redmine proposal: removal of ON_QA and Verified issue states which we don't use 15:19:07 Redmine Proposal of the Week (RPotW) 15:19:15 +1 15:19:23 makes sense to me - having options we don't use just confuses users 15:19:29 +1 15:20:06 these are easy to remove in one place here https://pulp.plan.io/issue_statuses 15:20:39 can I push the buttons this time?!? pleeeeeeeeeeeeeeeeeeeease??? 15:20:43 :) 15:21:03 yes but you have to use thumbs 15:21:13 oh god, I'm f'd 15:21:16 haha 15:21:20 +1 15:21:25 this task has a thumb-only requirement 15:21:48 whoa, I def need to slow down mouse-accel if I'm just using thumbs, hang on 15:22:30 ok, do we have consensus? 15:22:40 I think so 15:23:08 Now i see, why it's the arm architecture that has a thumb-code... 15:24:18 aww - "Unable to delete issue status" 15:24:43 dunno if it's a permissions-thing or what 15:25:15 ggainey: shall I try to see if it's a perms thing? 15:25:22 go4it! 15:25:42 yeah it was a perms thing 15:25:44 it worked for me 15:26:03 #endmeeting 15:26:03 !end