14:30:35 <dkliban> #startmeeting Pulp Triage 2016-05-13 14:30:35 <dkliban> !start 14:30:35 <pulpbot> Meeting started Fri May 13 14:30:35 2016 UTC and is due to finish in 60 minutes. The chair is dkliban. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:30:35 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:30:35 <pulpbot> The meeting name has been set to 'pulp_triage_2016_05_13' 14:30:35 <dkliban> #info dkliban has joined triage 14:30:35 <pulpbot> dkliban has joined triage 14:31:01 <ttereshc> !here 14:31:01 <ttereshc> #info ttereshc has joined triage 14:31:02 <pulpbot> ttereshc has joined triage 14:31:10 <pcreech> !here 14:31:10 <pcreech> #info pcreech has joined triage 14:31:10 <pulpbot> pcreech has joined triage 14:31:41 <jcline> Do I need to tell it I'm here still or does it just know because I talked? 14:31:51 <pcreech> I think you have to register as here 14:31:51 <jcline> Hmm. Guess I need to tell it. 14:31:56 <jcline> #info jcline has joined triage 14:31:56 <jcline> !here 14:31:57 <pulpbot> jcline has joined triage 14:32:19 <dkliban> I believe we have a quorum 14:32:28 <smyers> It won't let you !next without one :) 14:32:35 <dkliban> !next 14:32:37 <dkliban> #topic in Search API, restritcting fields does not work with Mongoengine - http://pulp.plan.io/issues/1332 14:32:37 <pulpbot> 16 issues left to triage: 1332, 1773, 1885, 1893, 1897, 1901, 1902, 1903, 1905, 1906, 1907, 1909, 1910, 1911, 1912, 1915 14:32:37 <pulpbot> Pulp Issue #1332 [NEW] (amacdona@redhat.com) - Priority: High | Severity: Medium 14:32:38 <pulpbot> in Search API, restritcting fields does not work with Mongoengine - http://pulp.plan.io/issues/1332 14:32:46 <dkliban> asmacdo: are you working on this ? 14:32:56 <smyers> The !propose accept behavior is still confusing as hell, it's worth pretending that command doesn't exist. 14:33:03 <smyers> !here 14:33:03 <smyers> #info smyers has joined triage 14:33:04 <pulpbot> smyers has joined triage 14:33:09 <asmacdo> dklibani took a look 14:33:16 <asmacdo> i think it needs to be a new bug 14:33:27 <asmacdo> restricting fields does work with mongoengine 14:33:47 <asmacdo> at least one is failing, with users, but at least repo search is working 14:33:49 <dkliban> asmacdo: you want to file a new issue? 14:34:01 <asmacdo> sure, i can do that 14:34:34 <dkliban> asmacdo: i am going to skip this issue, but after you write a new one, you should close this one 14:34:41 <asmacdo> ack 14:34:52 <mhrivnak> #info mhrivnak has joined triage 14:34:52 <mhrivnak> !here 14:34:52 <pulpbot> mhrivnak has joined triage 14:34:53 <smyers> +1 14:35:03 <dkliban> !skip 14:35:05 <pulpbot> 15 issues left to triage: 1773, 1885, 1893, 1897, 1901, 1902, 1903, 1905, 1906, 1907, 1909, 1910, 1911, 1912, 1915 14:35:05 <dkliban> #topic No "unprotected/http" option available for ostree repos - http://pulp.plan.io/issues/1773 14:35:06 <pulpbot> OSTree Support Issue #1773 [NEW] (unassigned) - Priority: Normal | Severity: Medium 14:35:06 <pulpbot> No "unprotected/http" option available for ostree repos - http://pulp.plan.io/issues/1773 14:35:24 <dkliban> we have skipped this one for about a month now 14:35:47 <smyers> yep 14:35:49 <mhrivnak> ya. and jortel is tied up right now, so he can't comment. 14:35:58 <dkliban> skip it again? 14:36:05 <bmbouter> what do we need to triage it? 14:36:20 <mhrivnak> we need scope. 14:36:30 <mhrivnak> but honestly, this should probably be a story. 14:36:43 <bmbouter> I can see that 14:36:52 <mhrivnak> I don't think it's a bug. It's lack of a behavior that they might want. 14:36:53 <jalbertson> does it need scope from jortel or someone else? 14:36:56 <smyers> It's not clear to me that this issue is blocked, since partha has replied since common #2 14:37:01 <smyers> comment 14:37:15 <mhrivnak> need scope from a mix of jortel and partha probably. 14:37:28 <smyers> I'm in favor of making it a story, and leaving it Normal/Medium for now 14:37:33 <bmbouter> +1 14:37:36 <mhrivnak> +1 14:37:41 <smyers> If it needs grease, it will squeak. :) 14:37:41 <bowlofeggs> !here 14:37:41 <bowlofeggs> #info bowlofeggs has joined triage 14:37:42 <pulpbot> bowlofeggs has joined triage 14:37:42 <dkliban> ok ... i am making it a story 14:37:56 <jcline> Fine with me 14:38:02 <dkliban> !next 14:38:04 <dkliban> #topic Pulp uploads are failing with "too many open files" error - http://pulp.plan.io/issues/1885 14:38:04 <pulpbot> 14 issues left to triage: 1885, 1893, 1897, 1901, 1902, 1903, 1905, 1906, 1907, 1909, 1910, 1911, 1912, 1915 14:38:05 <pulpbot> Pulp Issue #1885 [NEW] (unassigned) - Priority: Normal | Severity: Medium 14:38:06 <pulpbot> Pulp uploads are failing with "too many open files" error - http://pulp.plan.io/issues/1885 14:38:37 <dkliban> mhrivnak: this sounds bad 14:38:57 <smyers> But then in the comments, not so bad 14:38:58 <mhrivnak> It does, but I couldn't reproduce it, and it sounds like they are having trouble reproducing it. 14:39:10 <smyers> Not sure if pulp bug or RCM-patched-pulp bug 14:39:28 <bowlofeggs> we could wait a week 14:39:35 <jalbertson> this is not a priority for them - I had a conversation with dgregor regarding it 14:39:36 <smyers> mhrivnak, where did the number 6000 come from? 14:39:44 <mhrivnak> I made it up. 14:39:46 <smyers> Cool 14:39:52 <bmbouter> I don't think this is an actual bug 14:39:59 <dkliban> should we close it or skip it? 14:40:00 <smyers> I agree 14:40:10 <dkliban> close not a bug? 14:40:22 <bmbouter> I think so and I can do that with a comment on it 14:40:23 <smyers> I want to close it notabug pending a reproducer 14:40:29 <jcline> So I don't know much about upload, but don't we do it in chunks (not the HTTP chunked feature)? 14:40:29 <dkliban> bmbouter: thanks! 14:40:42 <jcline> Could that lead to a bunch of partial uploads with open file handles? 14:40:55 <bmbouter> it could, but after testing we couldn't reproduce 14:41:06 <smyers> The chunks should all be in-memory, streamed to a single file handle, in my experience. 14:41:09 <jcline> If the files uploaded are smaller than the chunk size maybe it wouldn't happen 14:41:20 <mhrivnak> smyers, the chunks come in different requests. 14:41:22 <jcline> Okay, I'm out of ideas then 14:41:41 <bowlofeggs> let's close but invite reproduction steps 14:41:45 <mhrivnak> In any case, I agree that closing and inviting a reproducer would be good. 14:41:46 <bmbouter> I want to fix it if its broken, but I don't see how without a reproducer 14:41:46 <ttereshc> maybe close as works for me? 14:42:10 <bowlofeggs> +1 14:42:10 <smyers> Yeah, I think worksforme is a more appropriate status 14:42:11 <dkliban> alright .. bmbouter is leaving a comment and closing it. we are moving to the next bug. 14:42:12 <smyers> good call 14:42:13 <jalbertson> +1 14:42:15 <bmbouter> +1 14:42:17 <bmbouter> doing it now 14:42:21 <dkliban> !next 14:42:23 <pulpbot> 13 issues left to triage: 1893, 1897, 1901, 1902, 1903, 1905, 1906, 1907, 1909, 1910, 1911, 1912, 1915 14:42:24 <dkliban> #topic pulp_docker does not support Docker < 1.10 with manifests that were published from Docker >= 1.10 - http://pulp.plan.io/issues/1893 14:42:24 <pulpbot> Docker Support Issue #1893 [NEW] (unassigned) - Priority: Normal | Severity: Medium 14:42:24 <pulpbot> pulp_docker does not support Docker < 1.10 with manifests that were published from Docker >= 1.10 - http://pulp.plan.io/issues/1893 14:42:39 * smyers facepalms 14:42:50 <bowlofeggs> this one is still unknown for priority 14:42:55 <bowlofeggs> unless jalbertson knows more 14:43:14 <jalbertson> bowlofeggs, I do not 14:43:23 <bowlofeggs> last i heard was that RCM was going to test a matrix of versions to see if the problem is immediate or not 14:43:33 <bowlofeggs> i had a meeting with them yesterday 14:43:39 <bowlofeggs> and they said they had not tested this yet 14:43:55 <bowlofeggs> we definitely have to do something, but the question is really just over priority 14:44:08 <smyers> It seems triagable based on that, since it's apparently not being treated as High priority 14:44:30 <dkliban> i think we should make it Normal priority 14:44:31 <bowlofeggs> true 14:44:34 <bowlofeggs> +1 14:44:41 <dkliban> any objections? 14:44:45 <jcline> +1 14:44:48 <smyers> Severity might be High, since pulp just doesn't work in this case 14:45:07 <dkliban> High severity, Normal priority 14:45:21 <mhrivnak> I'm still a little uncertain of the impact on users. 14:45:29 * smyers too 14:45:33 <mhrivnak> Having that matrix of test results would be very helpful. 14:46:02 <smyers> So normal/med prio and sev 14:46:05 <smyers> ? 14:46:22 <mhrivnak> I'm not sure we can know the priority without better understanding of the impact. 14:46:36 <ttereshc> !propose needinfo 14:46:36 <ttereshc> #idea Proposed for #1893: This issue cannot be triaged without more info. 14:46:37 <pulpbot> Proposed for #1893: This issue cannot be triaged without more info. 14:46:51 <dkliban> mhrivnak: do you proopose that we skip it and leave it untriaged? 14:47:09 <dkliban> someone needs to take action on it though 14:47:09 <mhrivnak> I think that would be a fine option. 14:47:23 <mhrivnak> Sounds like RCM is going to do some testing? 14:47:26 <bowlofeggs> rcm had volunteered to do that testing 14:47:30 <dkliban> ok 14:47:34 <dkliban> let's skip then 14:47:40 <dkliban> any objection to skipping? 14:47:57 <mhrivnak> I'll add a note asking for more info. 14:48:03 <dkliban> mhrivnak: thank you ! 14:48:10 <dkliban> !skip 14:48:12 <dkliban> #topic catalog entries not created for pre-existing units - http://pulp.plan.io/issues/1897 14:48:12 <pulpbot> 11 issues left to triage: 1897, 1901, 1902, 1903, 1905, 1906, 1907, 1910, 1911, 1912, 1915 14:48:12 <pulpbot> RPM Support Issue #1897 [ASSIGNED] (jortel@redhat.com) - Priority: Normal | Severity: Medium 14:48:13 <pulpbot> catalog entries not created for pre-existing units - http://pulp.plan.io/issues/1897 14:48:28 <dkliban> i think this was already triaged 14:48:29 <jcline> ah, we can skip that, jortel accidentally untriaged it 14:48:32 <smyers> I kinda like what's going on here, where the guy running triage isn't always the guy changing the issue 14:48:57 <smyers> So just add the triage check back? 14:49:04 <jcline> dkliban, I'll mark it as triaged again 14:49:10 <dkliban> jcline: thank you ! 14:49:17 <jortel> yeah, sorry .. didn't mean to untriage. no idea how it happened 14:49:22 <dkliban> !next 14:49:24 <dkliban> #topic Fix error handling during the erratum update - http://pulp.plan.io/issues/1901 14:49:24 <pulpbot> 10 issues left to triage: 1901, 1902, 1903, 1905, 1906, 1907, 1910, 1911, 1912, 1915 14:49:24 <pulpbot> RPM Support Issue #1901 [NEW] (unassigned) - Priority: Normal | Severity: Medium 14:49:25 <pulpbot> Fix error handling during the erratum update - http://pulp.plan.io/issues/1901 14:50:02 <dkliban> ttereshc: are you working on this already? 14:50:12 <ttereshc> no 14:50:29 <dkliban> is Normal priority, Medium severity appropriate for this? 14:50:48 <ttereshc> I think so 14:50:50 <bowlofeggs> sounds important to me 14:51:10 <jcline> Only if there's malformed errata running around 14:51:16 <mhrivnak> If we run into errata in the wild that can't be parsed for this reason, it'll be important to get clear feedback. 14:51:22 <bowlofeggs> oh wait 14:51:24 <jcline> Which shouldn't happen, and if it does you see this rather than a nicer message 14:51:30 <bowlofeggs> it's the malformed data one from last week 14:51:34 <smyers> jcline++ 14:51:34 <pulpbot> jcline's karma is now 1 14:51:35 <jcline> I think the error message is pretty clear 14:51:49 <bowlofeggs> #idea Proposed for #1901: Leave the issue as-is, accepting its current state. 14:51:49 <bowlofeggs> !propose accept 14:51:49 <pulpbot> Proposed for #1901: Leave the issue as-is, accepting its current state. 14:51:54 <smyers> I'm thinking that to change the error handling here might basically mean changing how pulp-admin displays errors 14:51:58 <bowlofeggs> dkliban: that was a real propose accept! 14:52:04 <mhrivnak> You just have to go digging for the error message, rather than seeing it right away. 14:52:05 <smyers> Which is a pretty huge deal 14:52:24 <mhrivnak> smyers, I don't think that's likely the case. 14:52:30 <jcline> Yeah, but that's true of tons of pulp-admin errors 14:52:48 <jcline> I'm not saying it's good, obviously. Just common. 14:52:54 <mhrivnak> well, maybe it's the case on this command specifically? 14:52:56 <smyers> Yeah, we can fix just this one, but it'll be just another one-off fix 14:53:04 <smyers> (jaoof) 14:53:10 <mhrivnak> Usually we can just raise a PulpCodedException, and the right thing happens. 14:53:21 <mhrivnak> no client-side work required. 14:53:37 <smyers> Is PulpExecutionException not a PulpCodedException? 14:53:44 <mhrivnak> But it's possible that isn't supported everywhere in pulp-admin yet? I don't recall the scope of that. 14:53:48 <smyers> (That would be appropriately hilarious) 14:53:58 <ttereshc> I think it s also good not to fail on the first erratum but try to update all of them 14:54:03 <jcline> smyers, I would not be surprised if it isn't 14:54:10 * smyers too 14:54:19 <jcline> Anyway, I'm fine with normal medium or normal low 14:54:21 <mhrivnak> don't think it is. 14:55:03 <dkliban> Normal/Medium .... any objections? 14:55:18 <bowlofeggs> do it 14:55:18 <mhrivnak> works for me. 14:55:29 <ttereshc> +1 14:55:35 <dkliban> !next 14:55:37 <pulpbot> 9 issues left to triage: 1902, 1903, 1905, 1906, 1907, 1910, 1911, 1912, 1915 14:55:37 <dkliban> #topic upload performance degrades as repo size increases - http://pulp.plan.io/issues/1902 14:55:38 <pulpbot> RPM Support Issue #1902 [NEW] (unassigned) - Priority: Normal | Severity: Medium 14:55:38 <pulpbot> upload performance degrades as repo size increases - http://pulp.plan.io/issues/1902 14:55:40 <mhrivnak> Probably a pretty easy fix, so someone could tack it on at the end of a sprint if they like, or a Friday afternoon. :) 14:55:51 <smyers> It's also probably worth a comment from mhrivnak including the PulpCodedException info on #1901 14:56:01 <mhrivnak> I'll add that comment. 14:56:17 <bmbouter> I feel #1902 is important for large pulp installs that do lots of uploading 14:56:25 <mhrivnak> 1902 is a regression in 2.8. It makes upload real bad. 14:56:26 <jcline> yeah 14:56:40 <bmbouter> suggest High prio 14:56:42 <dkliban> i say this is High / High ? 14:56:43 <bowlofeggs> !propose high med 14:56:43 <pulpbot> Error: "propose" is not a valid command. 14:56:47 * bmbouter is not sure how to propose 14:56:53 <bowlofeggs> #idea Proposed for #1902: Priority: High, Severity: Medium 14:56:53 <bowlofeggs> !propose triage high med 14:56:53 <pulpbot> Proposed for #1902: Priority: High, Severity: Medium 14:56:57 <dkliban> let's not use that feature. etherpad says so. 14:56:58 <smyers> This is pulp-admin rpm upload behavior? 14:56:59 <jcline> Either high high or high medium 14:57:11 <bowlofeggs> etherpad? 14:57:23 <mhrivnak> I only tested it with pulp-admin, but the regression is on the server side. 14:57:37 <smyers> Because what's slowing this down is likely duplicate nevra protection, which on upload happens per-unit, and will progressively slow down as more units are added. 14:57:42 <dkliban> the API performance degrades 14:57:48 <mhrivnak> oh. 14:57:51 <bowlofeggs> i don't think it's high severity - it doesn't crash, just gets slow 14:57:57 <smyers> Yeah. If I'm right, then we want this. 14:58:04 <smyers> It's slower for a very good reason. 14:58:23 <dkliban> smyers: makes sense ... i just thoguht our indexes would help alliviate the problem 14:58:28 <jcline> I hadn't thought of that 14:58:32 <bmbouter> me neither 14:58:36 <mhrivnak> The task went from averaging maybe 50-100ms to averaging almost 5 seconds as the repo got large. 14:58:43 <smyers> They do, I think. It'd be way worse without them. 14:58:48 <bmbouter> still though it's important so I suggest we give it high prio 14:58:50 <jcline> That's going to be rough on people with hundreds of thousands of rpms though, right? 14:58:53 * bmbouter has to go, ttyl 14:59:07 <smyers> Are people uploading hundreds of thousands of rpms one at a time? 14:59:16 <smyers> Maybe createrepo that pile and sync it the normal way? 14:59:18 <dkliban> smyers: yeah ... i think tht's how it works 14:59:22 <bowlofeggs> can't you only upload rpms one at a time? 14:59:30 <mhrivnak> it's one at a time. 14:59:38 <jcline> Well maybe hundreds of thousands, but I wouldn't be surprised if it was thousands at a time 14:59:54 <mhrivnak> Perhaps we can do the nevra protection a faster way for upload than for sync. 15:00:07 <mhrivnak> thousands at a time definitely happens. 15:00:36 <jcline> bowlofeggs, by "at a time" I just meant in a batch 15:01:15 <mhrivnak> I think this is worth a little investigation in the near term. 15:01:29 <dkliban> so high priority / medium severity? 15:01:35 <jalbertson> +1 15:01:45 <bowlofeggs> the postgres work will solve this problem 15:01:57 <bowlofeggs> because proper db design is really what's lacking here 15:01:57 <dkliban> yeah ... but we are not even close to that 15:02:10 <dkliban> so let's see what we can do in the short term 15:02:17 <mhrivnak> high/med works for me. 15:02:26 <dkliban> great! i am marking it as such 15:02:40 <dkliban> !next 15:02:42 <pulpbot> 8 issues left to triage: 1903, 1905, 1906, 1907, 1910, 1911, 1912, 1915 15:02:42 <dkliban> #topic RPM import traceback (non-utf-8 metadata slipping through) - http://pulp.plan.io/issues/1903 15:02:43 <pulpbot> Pulp Issue #1903 [NEW] (unassigned) - Priority: Normal | Severity: Medium 15:02:43 <pulpbot> RPM import traceback (non-utf-8 metadata slipping through) - http://pulp.plan.io/issues/1903 15:03:36 <mhrivnak> ah yes. We have some protection during sync against rpms with non-utf8 encoding, but no such protection during upload. 15:03:39 <bowlofeggs> i blieve RPMs are required to be UTF-8 15:03:51 <bowlofeggs> RPMs do not have a field to indicate what their encoding is 15:03:56 <dkliban> looks like there is a patch already 15:03:59 <bowlofeggs> so they need to be UTF-8 15:04:21 <bowlofeggs> latin-1 is not valid in an RPM afaik 15:04:30 <bowlofeggs> i had a tech-list thread about this a few years ago 15:04:35 <mhrivnak> the reporter was doing some work to try to fix it, so I added that patch as a quick way to help him/her move forward. 15:05:06 <bowlofeggs> that patch is not safe 15:05:18 <bowlofeggs> if you receive invalid encoding, it's not a good idea to assume that it's latin-1 15:05:25 <mhrivnak> I think the rpms in question are from suse, and suse themselves have a policy that all rpms must be utf-8 15:05:31 <mhrivnak> but the rpms are old enough that they don't want to fix them. 15:05:31 <bowlofeggs> that can and will result in corrupted data in the database 15:05:52 <bowlofeggs> there are hundreds of codecs 15:05:57 <mhrivnak> Indeed. We did have a lot of discussion about this a long time ago when the protection was added to the sync workflow. 15:06:08 <bowlofeggs> latin-1 is a popular one, but there ar emany others in use, especially in asia (the most populous continent) 15:06:27 <bowlofeggs> this patch would corrupt asian data 15:06:42 <bowlofeggs> it's better for us to fail with a good error message 15:06:46 <mhrivnak> FWIW, this patch would have upload do exactly what sync already does, so maybe we need to re-consider that behavior too? 15:06:47 <bowlofeggs> about the rpm having invalid data 15:07:09 <jalbertson> regardless of the patch, do we want to triage the problem and then have someone review and determine whether or not the patch is the right solution 15:07:25 <jalbertson> or do we not think this is an issue 15:07:53 <smyers> I think that's the problem. It appears to boil down to "Do we want to fix pulp to allow uploading invalid RPMs?" 15:07:55 <bowlofeggs> i think we should mkae the issue be about bad error messages 15:08:16 <mhrivnak> If we do that, we need to also consider changing how sync handles the same situation. 15:08:46 <jalbertson> or should we skip and have people add comments to the issue and re-evaluate? 15:08:57 <mhrivnak> Sounds like we need to nail down the "right behavior" first, and then make sure both places do it. 15:09:24 <dkliban> so i propose that bowlofeggs and mhrivnak leave some comments on the issue 15:09:29 <dkliban> we will skip it for today 15:09:40 <smyers> That's a new task, right? For deciding the right option? 15:10:00 <dkliban> let's start by having a conversation in the comments of this issue though 15:10:06 <jalbertson> +1 15:10:38 <dkliban> mhrivnak and bowlofeggs ... does that work for you? and we'll move on to the next issue 15:10:42 <mhrivnak> works for me. 15:10:56 <bowlofeggs> +1 15:10:59 <dkliban> !next 15:11:02 <pulpbot> 7 issues left to triage: 1905, 1906, 1907, 1910, 1911, 1912, 1915 15:11:03 <dkliban> #topic Streamer SSL cert not added to Pulp's trust store on RHEL 6 - http://pulp.plan.io/issues/1905 15:11:03 <pulpbot> Packaging Issue #1905 [NEW] (unassigned) - Priority: Normal | Severity: Medium 15:11:03 <pulpbot> Streamer SSL cert not added to Pulp's trust store on RHEL 6 - http://pulp.plan.io/issues/1905 15:11:30 <ichimonji10> ipanova: ++ 15:11:30 <pulpbot> ipanova: 's karma is now 1 15:11:57 <jcline> To summarize this, the CA used for apache doesn't end up the trust store on rhel6, but it does everywhere else. 15:12:13 <dkliban> sounds like a very bad problem 15:12:20 <jcline> It's an easy fix, there must just be some difference in RHEL 6. 15:12:26 <bowlofeggs> this is for CI only, fwiw 15:12:28 <jcline> This is just for our test infrastructure 15:12:31 <bowlofeggs> i say high/med 15:12:40 <smyers> high/low, even? 15:12:45 <bowlofeggs> yeah high/low 15:12:47 <jcline> either is fine with me 15:12:57 <smyers> high prio, low sev, to be clear 15:13:01 <smyers> !propose high low 15:13:01 <pulpbot> Error: "propose" is not a valid command. 15:13:05 <smyers> :( 15:13:09 <smyers> !propose triage high low 15:13:09 <smyers> #idea Proposed for #1905: Priority: High, Severity: Low 15:13:10 <pulpbot> Proposed for #1905: Priority: High, Severity: Low 15:13:19 <bowlofeggs> https://en.wikipedia.org/wiki/High/Low_%28Nada_Surf_album%29 15:13:19 <mhrivnak> +1 15:13:20 <pulpbot> Title: High/Low (Nada Surf album) - Wikipedia, the free encyclopedia (at en.wikipedia.org) 15:13:41 <dkliban> works for me 15:13:54 <dkliban> i am marking it as High priority Low severity 15:14:22 <dkliban> !next 15:14:24 <pulpbot> 6 issues left to triage: 1906, 1907, 1910, 1911, 1912, 1915 15:14:24 <dkliban> #topic Consumers are added to group but not bound to group repos - http://pulp.plan.io/issues/1906 15:14:25 <pulpbot> RPM Support Issue #1906 [NEW] (unassigned) - Priority: Normal | Severity: Medium 15:14:25 <pulpbot> Consumers are added to group but not bound to group repos - http://pulp.plan.io/issues/1906 15:14:44 <bowlofeggs> our consumer and repo grouping features have always been pretty half-done 15:14:50 <dkliban> is this a story or an isuse? 15:14:52 <jcline> 1/4 done, really 15:14:53 <bowlofeggs> this is kind of a story 15:15:04 <mhrivnak> agreed. 15:15:10 <bowlofeggs> because it's like "why did you make this feature when you can't do hardly anything with it?" 15:15:13 <smyers> +1 story 15:15:29 <bowlofeggs> yeah switch to story, but we also should really actually do it 15:16:11 <dkliban> bowlofeggs: do you propose it for a sprint candidate? 15:16:15 <mhrivnak> We may not have a need for consumer groups in pulp 3, FWIW. 15:16:47 <dkliban> i think marking it as a story is enough for right now. if anyone has particular interest, bring it up at sprint planning 15:16:53 <mhrivnak> Or if we do, a re-think is certainly appropriate. 15:17:24 <jalbertson> dkliban, agreed 15:17:36 <ipanova> i think it is dup 15:17:52 <bowlofeggs> let's move on 15:18:04 <bowlofeggs> in general, i think we can do triage faster than this 15:18:07 <dkliban> ipanova: if you think so, please link it to the other issue 15:18:13 <dkliban> !next 15:18:13 <ipanova> dkliban: working on this 15:18:14 <pulpbot> 5 issues left to triage: 1907, 1910, 1911, 1912, 1915 15:18:15 <dkliban> #topic python-pulp-streamer is not pulled with groupinstall pulp-server-qpid - http://pulp.plan.io/issues/1907 15:18:15 <pulpbot> Pulp Issue #1907 [NEW] (unassigned) - Priority: Normal | Severity: Medium 15:18:15 <pulpbot> python-pulp-streamer is not pulled with groupinstall pulp-server-qpid - http://pulp.plan.io/issues/1907 15:18:22 <dkliban> ipanova: thanks! 15:18:26 <bowlofeggs> #idea Proposed for #1907: Leave the issue as-is, accepting its current state. 15:18:26 <bowlofeggs> !propose accept 15:18:26 <pulpbot> Proposed for #1907: Leave the issue as-is, accepting its current state. 15:18:37 <bowlofeggs> actually 15:18:38 <jcline> This is a docs bug, not normal normal is fine 15:18:39 <bowlofeggs> let's not do this 15:18:59 <bowlofeggs> shoudln't the streamer not always get installed? 15:19:05 <bowlofeggs> it's a separate thing 15:19:05 <smyers> That's what I thought 15:19:10 <dkliban> same here 15:19:11 <mhrivnak> me too 15:19:12 <jcline> There's a whole bunch of conversation about that, yes 15:19:13 <smyers> NOTABUG 15:19:28 <jcline> Ultimately we decided it should be better documented 15:19:39 <dkliban> yeah ... i think it should be a documentation bug 15:19:49 <mhrivnak> sounds good. 15:20:06 <bowlofeggs> notabug +21 15:20:09 <smyers> Probably an important one, though, since the confusion causes breakage 15:20:22 <bowlofeggs> let's move on 15:20:27 <bowlofeggs> 10 min left 15:20:39 <ipanova> dkliban: #1706 should be closed as dup of https://pulp.plan.io/issues/167 15:20:41 <pulpbot> Title: Story #167: [RFE] new consumers do not auto subscribe to already bound consumer group repos - Pulp (at pulp.plan.io) 15:20:42 <jalbertson> hold on - are you marking it as a documentation bug and accepting it or rejecting? 15:20:46 <smyers> I'm thinking don't close it, just add docs and easy fix, high prio, normal sev 15:21:05 <bowlofeggs> +1 to smyers' suggestion 15:21:05 <dkliban> i am accepting it as a documentation bug with Normal priority Medium severity 15:21:11 <jcline> Docs bug and accepting it is what should happen, I think 15:21:14 <jalbertson> +1 15:21:15 <smyers> high prio 15:21:22 <smyers> We broke a dude with bad docs 15:21:29 <bowlofeggs> !propose triage high med 15:21:29 <bowlofeggs> #idea Proposed for #1907: Priority: High, Severity: Medium 15:21:30 <pulpbot> Proposed for #1907: Priority: High, Severity: Medium 15:21:36 <dkliban> !accept 15:21:36 <dkliban> #agreed Priority: High, Severity: Medium 15:21:37 <pulpbot> Current proposal accepted: Priority: High, Severity: Medium 15:21:38 <pulpbot> 4 issues left to triage: 1910, 1911, 1912, 1915 15:21:39 <dkliban> #topic Errata update fails when id of the repo is added to the existing collection - http://pulp.plan.io/issues/1910 15:21:39 <pulpbot> RPM Support Issue #1910 [POST] (ttereshc) - Priority: Normal | Severity: Medium | Target Release: 2.8.4 15:21:39 <pulpbot> Errata update fails when id of the repo is added to the existing collection - http://pulp.plan.io/issues/1910 15:21:59 <smyers> POST 15:22:01 <smyers> !propose accept 15:22:01 <smyers> #idea Proposed for #1910: Leave the issue as-is, accepting its current state. 15:22:02 <pulpbot> Proposed for #1910: Leave the issue as-is, accepting its current state. 15:22:10 <bowlofeggs> yeah let's !next 15:22:30 <ttereshc> +1 15:22:31 <smyers> ...but tick that triaged box :) 15:22:37 <mhrivnak> +1 15:22:52 <dkliban> !next 15:22:54 <dkliban> #topic productid.gz unit needs to be treated the same as other metadata files - http://pulp.plan.io/issues/1911 15:22:54 <pulpbot> 3 issues left to triage: 1911, 1912, 1915 15:22:54 <pulpbot> RPM Support Issue #1911 [NEW] (unassigned) - Priority: High | Severity: Medium | Target Release: 2.8.4 15:22:55 <pulpbot> productid.gz unit needs to be treated the same as other metadata files - http://pulp.plan.io/issues/1911 15:23:05 <smyers> I'm thinking that if an issue goes to POST and it isn't triaged, well...probably we (devs) should try to remember to check the box. 15:23:28 <bowlofeggs> agreed 15:23:37 <bowlofeggs> !propose accept 15:23:37 <bowlofeggs> #idea Proposed for #1911: Leave the issue as-is, accepting its current state. 15:23:38 <pulpbot> Proposed for #1911: Leave the issue as-is, accepting its current state. 15:23:44 <mhrivnak> interesting. 15:23:47 <jcline> +1 15:24:14 <bowlofeggs> let's move on 15:24:15 <dkliban> any objections? 15:24:18 <mhrivnak> +1 15:24:19 <bowlofeggs> <6 min left 15:24:37 <dkliban> !next 15:24:39 <dkliban> #topic Add MD5 checksum element to data type elements in repomd.xml file - http://pulp.plan.io/issues/1912 15:24:39 <pulpbot> 2 issues left to triage: 1912, 1915 15:24:40 <pulpbot> RPM Support Issue #1912 [NEW] (unassigned) - Priority: Normal | Severity: Medium 15:24:41 <pulpbot> Add MD5 checksum element to data type elements in repomd.xml file - http://pulp.plan.io/issues/1912 15:24:55 <bowlofeggs> i think !care broke 15:24:58 <robnester> If anyone has a question on this, I'm the reporter. 15:25:00 <bowlofeggs> robnester: this is you ^ 15:25:03 <robnester> yup 15:25:04 <bowlofeggs> haha 15:25:29 <robnester> maybe i have to !here for it to !care ? 15:25:34 <mhrivnak> Perhaps this is a story. 15:25:50 <jcline> We could probably do all supported checksum types, right? 15:25:53 <dkliban> it is a story. we should probably implement this soon 15:26:16 <smyers> No, you just have to !care during the current triage session 15:26:28 <dkliban> after !start 15:26:35 <robnester> ah 15:26:37 <robnester> ack 15:26:45 <dkliban> anyway, any objection to marking it as a story with high priority? 15:26:54 <bowlofeggs> +1 15:26:55 <mhrivnak> Is "validation-checksum" already part of the spec for repomd.xml? If there even is a spec? :) 15:27:08 <robnester> mhrivnak: I just made that up. 15:27:29 <robnester> mhrivnak: to be clear I don't care what the entity is called, i just need the md5 for the metadata file in repomd.xml 15:27:36 <mhrivnak> Gotcha. So for that kind of change, the first stop should probably be the createrepo_c folks. 15:28:04 <dkliban> mhrivnak: want to leave some comments on the story? 15:28:09 <smyers> mhrivnak, are you proposing we close it? 15:28:13 <mhrivnak> Or maybe there's another way for us to provide the checksum. 15:28:15 <jcline> I think we generate the repomd.xml ourselves 15:28:31 <smyers> But according to some rules, right? (he asked meekly) 15:28:32 <mhrivnak> We definitely generate it, but we don't control the schema. 15:28:36 <jcline> Until we use createrepo_c, there's nothing they can do. It would be nice to make sure it also happens in that project, though 15:28:55 <mhrivnak> I think they are the most-likely defacto owners of any schema that may or may not exist. ;0 15:28:57 <mhrivnak> er, ;) 15:29:10 <smyers> I think it needs to happen there *first*, not after we implement some schema-breaking change 15:29:16 <mhrivnak> +1 15:29:18 <jcline> Oh, we should definitely work with upstream as part of this story 15:29:36 <dkliban> jcline and mhrivnak, please leave feedback on issue 1912 15:29:38 <mhrivnak> We can make this a story, and I'll add a comment. 15:29:44 <smyers> +1 15:29:49 <dkliban> we are now moving on to the next issue 15:29:55 <dkliban> !next 15:29:57 <dkliban> #topic expose connect_timeout and read_timeout via configuration - http://pulp.plan.io/issues/1915 15:29:57 <pulpbot> 1 issues left to triage: 1915 15:29:57 <pulpbot> Nectar Issue #1915 [NEW] (unassigned) - Priority: Normal | Severity: Low 15:29:58 <pulpbot> expose connect_timeout and read_timeout via configuration - http://pulp.plan.io/issues/1915 15:29:59 <smyers> Good idea, but not pulp's problem to solve 15:31:13 <jcline> A lot of people have run into problems with this setting not being changeable because of proxies 15:31:20 <smyers> ugh I can't read non-unified diffs 15:31:39 <smyers> !propose other Convert to story to make the read timeout configurable via settings 15:31:39 <smyers> #idea Proposed for #1915: Convert to story to make the read timeout configurable via settings 15:31:39 <pulpbot> Proposed for #1915: Convert to story to make the read timeout configurable via settings 15:31:39 <dkliban> this is a story also 15:31:43 <mhrivnak> +1 15:31:48 <jcline> It's easy to fix, and a lot of people would benefit 15:31:49 <ttereshc> +1 15:31:56 <smyers> blammo 15:32:10 <dkliban> agreed! 15:32:13 <dkliban> moving on 15:32:18 <dkliban> !next 15:32:20 <pulpbot> No issues to triage. 15:32:32 <dkliban> #endmeeting 15:32:32 <dkliban> !end