15:30:18 <fao89> #startmeeting Pulp Triage 2020-02-07 15:30:18 <fao89> !start 15:30:18 <fao89> #info fao89 has joined triage 15:30:18 <pulpbot> 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 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 15:30:18 <pulpbot> The meeting name has been set to 'pulp_triage_2020-02-07' 15:30:18 <pulpbot> fao89: fao89 has joined triage 15:30:31 <fao89> !next 15:30:32 <pulpbot> fao89: 5 issues left to triage: 6105, 6104, 6098, 6045, 5991 15:30:32 <fao89> #topic https://pulp.plan.io/issues/6105 15:30:33 <pulpbot> RM 6105 - daviddavis - ASSIGNED - Nightly builds of pulpcore are failing 15:30:34 <pulpbot> https://pulp.plan.io/issues/6105 15:30:37 <ggainey> #info ggainey has joined triage 15:30:37 <ggainey> !here 15:30:37 <pulpbot> ggainey: ggainey has joined triage 15:30:54 <fao89> #idea Proposed for #6105: accept and add to sprint 15:30:54 <fao89> !propose other accept and add to sprint 15:30:54 <pulpbot> fao89: Proposed for #6105: accept and add to sprint 15:30:59 <ggainey> +1 15:31:20 <fao89> #agreed accept and add to sprint 15:31:20 <fao89> !accept 15:31:20 <pulpbot> fao89: Current proposal accepted: accept and add to sprint 15:31:21 <pulpbot> fao89: 4 issues left to triage: 6104, 6098, 6045, 5991 15:31:21 <fao89> #topic https://pulp.plan.io/issues/6104 15:31:22 <pulpbot> RM 6104 - daviddavis - NEW - pulp_file performance test takes too long for Travis 15:31:23 <pulpbot> https://pulp.plan.io/issues/6104 15:31:45 <fao89> #idea Proposed for #6104: accept and add to sprint 15:31:45 <fao89> !propose other accept and add to sprint 15:31:46 <pulpbot> fao89: Proposed for #6104: accept and add to sprint 15:31:48 <mikedep333> #info mikedep333 has joined triage 15:31:48 <mikedep333> !here 15:31:48 <pulpbot> mikedep333: mikedep333 has joined triage 15:32:34 <ggainey> isn't there work bein done on pulp_file performance? 15:33:01 <mikedep333> daviddavis? fao89? 15:33:01 <fao89> I think daviddavis and lmjachky_ are working on it 15:33:28 <daviddavis> #info daviddavis has joined triage 15:33:28 <daviddavis> !here 15:33:28 <pulpbot> daviddavis: daviddavis has joined triage 15:33:30 <ggainey> 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 <daviddavis> +1 15:33:41 <daviddavis> I can do that 15:34:00 <fao89> #agreed accept and add to sprint 15:34:00 <fao89> !accept 15:34:00 <pulpbot> fao89: Current proposal accepted: accept and add to sprint 15:34:02 <fao89> #topic https://pulp.plan.io/issues/6098 15:34:02 <pulpbot> fao89: 3 issues left to triage: 6098, 6045, 5991 15:34:03 <pulpbot> RM 6098 - mdepaulo@redhat.com - NEW - Pulp gunicorn times out when trying to list all packages 15:34:04 <pulpbot> https://pulp.plan.io/issues/6098 15:34:22 <daviddavis> hmm, so they're trying to query 10000 packages? 15:34:34 <mikedep333> Yes, it is a valid use case I suppose. 15:34:49 <fao89> #idea Proposed for #6098: Leave the issue as-is, accepting its current state. 15:34:49 <fao89> !propose accept 15:34:49 <pulpbot> fao89: Proposed for #6098: Leave the issue as-is, accepting its current state. 15:34:54 <ggainey> yeah, +1 15:35:01 <daviddavis> I kinda feel like you should expect to have to change timeouts if you want to query 10000 records 15:35:10 <daviddavis> but 30s does seem small 15:35:11 <mikedep333> Q: I would pulpcore-content need a longer timeout, or just pulpcore-api? 15:35:20 <daviddavis> just pulpcore-api I think 15:35:46 <mikedep333> 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 <daviddavis> I'm fine with that I suppose 15:36:13 <mikedep333> which is 30s 15:36:14 <mikedep333> 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 <fao89> 120s sounds good to me 15:36:54 <ggainey> 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 <ggainey> so +1 to 120s 15:37:11 <daviddavis> I was thinking 60 but 120 is ok 15:37:19 <fao89> we can try both 15:37:30 <ggainey> sure 15:37:31 <mikedep333> Great, I'll do that. 15:37:38 <fao89> #agreed Leave the issue as-is, accepting its current state. 15:37:38 <fao89> !accept 15:37:38 <pulpbot> fao89: Current proposal accepted: Leave the issue as-is, accepting its current state. 15:37:39 <pulpbot> fao89: 2 issues left to triage: 6045, 5991 15:37:39 <fao89> #topic https://pulp.plan.io/issues/6045 15:37:40 <pulpbot> RM 6045 - osapryki - NEW - Pulp content app looses database connection 15:37:41 <pulpbot> https://pulp.plan.io/issues/6045 15:37:50 <mikedep333> 120s, since a user's virtual machine might be having a slow day. Or a user may have 20,000 packages. 15:37:50 <dawalker> #info dawalker has joined triage 15:37:50 <dawalker> !here 15:37:50 <pulpbot> dawalker: dawalker has joined triage 15:38:02 <daviddavis> oh I was suppose to look into 6045 15:38:14 <fao89> skip? 15:38:18 <ggainey> mikedep333: yeah - some rhel repos are 15-17K, iirc 15:38:47 <daviddavis> yea, also we're waiting for user feedback 15:38:53 <ggainey> ah, kk 15:39:01 <fao89> !skip 15:39:02 <fao89> #topic https://pulp.plan.io/issues/5991 15:39:02 <pulpbot> fao89: 1 issues left to triage: 5991 15:39:03 <pulpbot> RM 5991 - jsherril@redhat.com - NEW - Sync fails with TypeError: unsupported operand type(s) for -=: 'Retry' and 'int' 15:39:04 <pulpbot> https://pulp.plan.io/issues/5991 15:39:18 <daviddavis> I think we can close this out 15:39:26 <fao89> yay! 15:39:27 <daviddavis> see https://pulp.plan.io/issues/5991#note-2 15:39:47 <dawalker> +1 15:39:49 <fao89> #idea Proposed for #5991: close it 15:39:49 <fao89> !propose other close it 15:39:49 <pulpbot> fao89: Proposed for #5991: close it 15:39:55 <ggainey> +1 15:39:55 <mikedep333> 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 <fao89> RHEL 7 is 20000+ 15:40:32 <fao89> #agreed close it 15:40:32 <fao89> !accept 15:40:33 <pulpbot> fao89: Current proposal accepted: close it 15:40:33 <daviddavis> mikedep333 ggainey any idea what the use case is for querying everything at once? 15:40:34 <pulpbot> fao89: No issues to triage. 15:40:41 <ggainey> yeah, the longer since release, the larger, since rhel keeps all nevras 15:40:45 <fao89> Open floor! 15:40:50 <daviddavis> we sync from APIs all the time and just page through them 15:41:32 <mikedep333> fao89: https://pkgs.org/ says that CentOS 7's main repo (the RHEL7 main repo + RHEL7 optional) is 10,047. 15:42:28 <ggainey> 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 <mikedep333> We have to assume that some people are going to get the entire list, and then parse it in something else. 15:42:57 <ggainey> yup 15:43:06 <ggainey> ETL is A Thing 15:43:32 <fao89> 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 <daviddavis> 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 <mikedep333> 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 <ggainey> daviddavis: when does a high default hurt? 15:44:13 <mikedep333> ^ 15:44:22 <ggainey> daviddavis: just in the "you can't really get there" case? 15:44:28 <daviddavis> when you don't realize you're running a huge query 15:44:32 <mikedep333> I mean, if a task will hang, it will hurt users. 15:44:32 <ggainey> (which is def A Thing as well, yeah) 15:45:05 <mikedep333> What I could do is set the value in the pulp_rpm_prerequisites role. So the order of precedence would be: 15:45:10 <mikedep333> highest: user-specified 15:45:21 <mikedep333> medium: pulp_rpm_prerequisites specified 15:45:28 <daviddavis> 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 <mikedep333> lowest: pulp3 default 15:45:59 <daviddavis> IMO, I think we should set the default to 120 and make it easy for users to change it 15:46:09 <daviddavis> mikedep333: that makes sense to me 15:46:15 <mikedep333> daviddavis: I say we do that. We can always increase it later. 15:46:17 <ggainey> that works for me - 120s is a reasonable compromise (imho, anyway) 15:46:30 <mikedep333> And users will have a simple variable to chang eit. 15:46:34 <daviddavis> +1 15:46:49 <fao89> +1 15:46:52 <ggainey> 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 <ggainey> coolio 15:47:41 <mikedep333> ggainey: I agree, I'll list the implications. 15:47:45 <daviddavis> cool 15:47:47 <ggainey> sounds like a fine plan 15:48:22 <fao89> it would be good to add notes - https://pulp.plan.io/issues/6098 15:48:28 <ggainey> yes please 15:48:45 <mikedep333> I'm copying and pasting this IRC log, then trimming it now for it. 15:48:49 <ggainey> +1 15:48:54 <daviddavis> mikedep333++ 15:48:54 <pulpbot> daviddavis: mikedep333's karma is now 62 15:48:57 <ggainey> mikedep333++ 15:48:57 <pulpbot> ggainey: mikedep333's karma is now 63 15:49:00 <ggainey> daviddavis++ 15:49:00 <pulpbot> ggainey: daviddavis's karma is now 273 15:49:01 <fao89> mikedep333++ 15:49:02 <pulpbot> fao89: mikedep333's karma is now 64 15:49:04 <ggainey> good discussion gang 15:49:15 <fao89> gang++ 15:49:15 <pulpbot> fao89: gang's karma is now 1 15:49:19 <ggainey> heh 15:49:21 <daviddavis> !friday 15:49:21 <pulpbot> ♪ It's Friday, Friday, gotta get down on Friday ♪ 15:49:27 <fao89> !pulp 15:49:27 <pulpbot> 🍊 Yay, Pulp! 🍊 Go team go! 🍊 15:49:27 * ggainey dances 15:50:08 <fao89> is this the end of open floor or we have more to discuss? 15:50:28 <mikedep333> 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 <ggainey> can I get someone to review https://github.com/pulp/pulp_rpm/pull/1594 please? 15:50:41 <ggainey> mikedep333: ha! nice! 15:51:08 <mikedep333> https://docs.google.com/presentation/d/1V8iqhaiSFsXoogfKCPAqFvbT3jmSkT8eOgG-yuVjz_M 15:51:41 <daviddavis> fao89: yea, +1 to end 15:51:47 <daviddavis> ggainey: I'll take a look 15:51:51 <ggainey> thank you sir 15:52:13 <fao89> mikedep333++ 15:52:13 <pulpbot> fao89: mikedep333's karma is now 65 15:52:32 <fao89> for the presentation and for using ricky & morty 15:52:38 <fao89> #endmeeting 15:52:38 <fao89> !end