15:30:18 #startmeeting Pulp Triage 2020-02-07 15:30:18 !start 15:30:18 #info fao89 has joined triage 15:30:18 Meeting started Fri Feb 7 15:30:18 2020 UTC. The chair is fao89. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:30:18 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:30:18 The meeting name has been set to 'pulp_triage_2020-02-07' 15:30:18 fao89: fao89 has joined triage 15:30:31 !next 15:30:32 fao89: 5 issues left to triage: 6105, 6104, 6098, 6045, 5991 15:30:32 #topic https://pulp.plan.io/issues/6105 15:30:33 RM 6105 - daviddavis - ASSIGNED - Nightly builds of pulpcore are failing 15:30:34 https://pulp.plan.io/issues/6105 15:30:37 #info ggainey has joined triage 15:30:37 !here 15:30:37 ggainey: ggainey has joined triage 15:30:54 #idea Proposed for #6105: accept and add to sprint 15:30:54 !propose other accept and add to sprint 15:30:54 fao89: Proposed for #6105: accept and add to sprint 15:30:59 +1 15:31:20 #agreed accept and add to sprint 15:31:20 !accept 15:31:20 fao89: Current proposal accepted: accept and add to sprint 15:31:21 fao89: 4 issues left to triage: 6104, 6098, 6045, 5991 15:31:21 #topic https://pulp.plan.io/issues/6104 15:31:22 RM 6104 - daviddavis - NEW - pulp_file performance test takes too long for Travis 15:31:23 https://pulp.plan.io/issues/6104 15:31:45 #idea Proposed for #6104: accept and add to sprint 15:31:45 !propose other accept and add to sprint 15:31:46 fao89: Proposed for #6104: accept and add to sprint 15:31:48 #info mikedep333 has joined triage 15:31:48 !here 15:31:48 mikedep333: mikedep333 has joined triage 15:32:34 isn't there work bein done on pulp_file performance? 15:33:01 daviddavis? fao89? 15:33:01 I think daviddavis and lmjachky_ are working on it 15:33:28 #info daviddavis has joined triage 15:33:28 !here 15:33:28 daviddavis: daviddavis has joined triage 15:33:30 I mean, we def need to get past the Travis fails - I guess accept-and-add, and then jack the number back up once the perf-changes hit would be its own thing 15:33:40 +1 15:33:41 I can do that 15:34:00 #agreed accept and add to sprint 15:34:00 !accept 15:34:00 fao89: Current proposal accepted: accept and add to sprint 15:34:02 #topic https://pulp.plan.io/issues/6098 15:34:02 fao89: 3 issues left to triage: 6098, 6045, 5991 15:34:03 RM 6098 - mdepaulo@redhat.com - NEW - Pulp gunicorn times out when trying to list all packages 15:34:04 https://pulp.plan.io/issues/6098 15:34:22 hmm, so they're trying to query 10000 packages? 15:34:34 Yes, it is a valid use case I suppose. 15:34:49 #idea Proposed for #6098: Leave the issue as-is, accepting its current state. 15:34:49 !propose accept 15:34:49 fao89: Proposed for #6098: Leave the issue as-is, accepting its current state. 15:34:54 yeah, +1 15:35:01 I kinda feel like you should expect to have to change timeouts if you want to query 10000 records 15:35:10 but 30s does seem small 15:35:11 Q: I would pulpcore-content need a longer timeout, or just pulpcore-api? 15:35:20 just pulpcore-api I think 15:35:46 Yeah. The question is what should be the default value then. We could make it default to undefined, and if undefined, let the system's default take effect. 15:36:08 I'm fine with that I suppose 15:36:13 which is 30s 15:36:14 But I want the ansible-pulp value to be safe for most users, so we might want to set it to 120s. 15:36:33 120s sounds good to me 15:36:54 yeah, user said "Set the timeout to 120s. The query of all packages in rhel7 actually took less than a minute. Default 30s seems a little too short." 15:37:05 so +1 to 120s 15:37:11 I was thinking 60 but 120 is ok 15:37:19 we can try both 15:37:30 sure 15:37:31 Great, I'll do that. 15:37:38 #agreed Leave the issue as-is, accepting its current state. 15:37:38 !accept 15:37:38 fao89: Current proposal accepted: Leave the issue as-is, accepting its current state. 15:37:39 fao89: 2 issues left to triage: 6045, 5991 15:37:39 #topic https://pulp.plan.io/issues/6045 15:37:40 RM 6045 - osapryki - NEW - Pulp content app looses database connection 15:37:41 https://pulp.plan.io/issues/6045 15:37:50 120s, since a user's virtual machine might be having a slow day. Or a user may have 20,000 packages. 15:37:50 #info dawalker has joined triage 15:37:50 !here 15:37:50 dawalker: dawalker has joined triage 15:38:02 oh I was suppose to look into 6045 15:38:14 skip? 15:38:18 mikedep333: yeah - some rhel repos are 15-17K, iirc 15:38:47 yea, also we're waiting for user feedback 15:38:53 ah, kk 15:39:01 !skip 15:39:02 #topic https://pulp.plan.io/issues/5991 15:39:02 fao89: 1 issues left to triage: 5991 15:39:03 RM 5991 - jsherril@redhat.com - NEW - Sync fails with TypeError: unsupported operand type(s) for -=: 'Retry' and 'int' 15:39:04 https://pulp.plan.io/issues/5991 15:39:18 I think we can close this out 15:39:26 yay! 15:39:27 see https://pulp.plan.io/issues/5991#note-2 15:39:47 +1 15:39:49 #idea Proposed for #5991: close it 15:39:49 !propose other close it 15:39:49 fao89: Proposed for #5991: close it 15:39:55 +1 15:39:55 ggainey: EPEL is 13512. If a RHEL repo is 15-17K, then 90s is probably typical, and a slow machine would need like 180s. 15:40:24 RHEL 7 is 20000+ 15:40:32 #agreed close it 15:40:32 !accept 15:40:33 fao89: Current proposal accepted: close it 15:40:33 mikedep333 ggainey any idea what the use case is for querying everything at once? 15:40:34 fao89: No issues to triage. 15:40:41 yeah, the longer since release, the larger, since rhel keeps all nevras 15:40:45 Open floor! 15:40:50 we sync from APIs all the time and just page through them 15:41:32 fao89: https://pkgs.org/ says that CentOS 7's main repo (the RHEL7 main repo + RHEL7 optional) is 10,047. 15:42:28 daviddavis: "what's in this repo" is def something ppl want to know - "I want to pull *everything* into my graphing-routine", for example - you def could say "use the paging API", but I guarantee users will push back, and it's a pretty simple fix to just raise the default to something larger-but-not-unreasonable 15:42:53 We have to assume that some people are going to get the entire list, and then parse it in something else. 15:42:57 yup 15:43:06 ETL is A Thing 15:43:32 mikedep333, I got it when I was looking into performance problem: https://www.redhat.com/archives/pulp-dev/2019-November/msg00084.html 15:43:33 mikedep333 ggainey yea, but I would assume it should be on users to raise their default. my concern is that a high default isn't good for most users 15:43:58 When I was doing systems engineering at a Linux distro user org with lots of requirements, we did that and then queried license info for every single package. 15:44:01 daviddavis: when does a high default hurt? 15:44:13 ^ 15:44:22 daviddavis: just in the "you can't really get there" case? 15:44:28 when you don't realize you're running a huge query 15:44:32 I mean, if a task will hang, it will hurt users. 15:44:32 (which is def A Thing as well, yeah) 15:45:05 What I could do is set the value in the pulp_rpm_prerequisites role. So the order of precedence would be: 15:45:10 highest: user-specified 15:45:21 medium: pulp_rpm_prerequisites specified 15:45:28 if users are submitting requests that take 180s or more than they're really taxing the system and they may not realize it 15:45:36 lowest: pulp3 default 15:45:59 IMO, I think we should set the default to 120 and make it easy for users to change it 15:46:09 mikedep333: that makes sense to me 15:46:15 daviddavis: I say we do that. We can always increase it later. 15:46:17 that works for me - 120s is a reasonable compromise (imho, anyway) 15:46:30 And users will have a simple variable to chang eit. 15:46:34 +1 15:46:49 +1 15:46:52 plus, "and users can change it" gives us a chance in the "how to change it" doc to say "you think you want to do this, but you really don't, and here's why" :) 15:47:04 coolio 15:47:41 ggainey: I agree, I'll list the implications. 15:47:45 cool 15:47:47 sounds like a fine plan 15:48:22 it would be good to add notes - https://pulp.plan.io/issues/6098 15:48:28 yes please 15:48:45 I'm copying and pasting this IRC log, then trimming it now for it. 15:48:49 +1 15:48:54 mikedep333++ 15:48:54 daviddavis: mikedep333's karma is now 62 15:48:57 mikedep333++ 15:48:57 ggainey: mikedep333's karma is now 63 15:49:00 daviddavis++ 15:49:00 ggainey: daviddavis's karma is now 273 15:49:01 mikedep333++ 15:49:02 fao89: mikedep333's karma is now 64 15:49:04 good discussion gang 15:49:15 gang++ 15:49:15 fao89: gang's karma is now 1 15:49:19 heh 15:49:21 !friday 15:49:21 ♪ It's Friday, Friday, gotta get down on Friday ♪ 15:49:27 !pulp 15:49:27 🍊 Yay, Pulp! 🍊 Go team go! 🍊 15:49:27 * ggainey dances 15:50:08 is this the end of open floor or we have more to discuss? 15:50:28 btw: I list the huge size of repos like EPEL/RHEL as a justification for using Pup in my presentation "Pulp 3: Stop using rsync to mirror EPEL" 15:50:31 can I get someone to review https://github.com/pulp/pulp_rpm/pull/1594 please? 15:50:41 mikedep333: ha! nice! 15:51:08 https://docs.google.com/presentation/d/1V8iqhaiSFsXoogfKCPAqFvbT3jmSkT8eOgG-yuVjz_M 15:51:41 fao89: yea, +1 to end 15:51:47 ggainey: I'll take a look 15:51:51 thank you sir 15:52:13 mikedep333++ 15:52:13 fao89: mikedep333's karma is now 65 15:52:32 for the presentation and for using ricky & morty 15:52:38 #endmeeting 15:52:38 !end