14:30:17 <ttereshc> #startmeeting Pulp Triage 2017-05-09 14:30:17 <ttereshc> #info ttereshc has joined triage 14:30:17 <pulpbot> Meeting started Tue May 9 14:30:17 2017 UTC and is due to finish in 60 minutes. The chair is ttereshc. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:30:17 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:30:17 <pulpbot> The meeting name has been set to 'pulp_triage_2017_05_09' 14:30:17 <pulpbot> ttereshc has joined triage 14:30:24 <mhrivnak> bmbouter, indeed we did consider that. Let's chat more post-triage. 14:30:25 <dkliban> !here 14:30:25 <dkliban> #info dkliban has joined triage 14:30:26 <pulpbot> dkliban has joined triage 14:30:29 <mhrivnak> !here 14:30:29 <mhrivnak> #info mhrivnak has joined triage 14:30:29 <pulpbot> mhrivnak has joined triage 14:30:54 <ttereshc> one more... 14:31:01 <beav> ttereshc: i still need to look at the issue from last week's traige about tasks and cancellation, i meant to do it last week but didnt get to it yet 14:31:10 <beav> just heads up since i didnt update the ticket yet:) 14:31:12 <dralley> !here 14:31:12 <dralley> #info dralley has joined triage 14:31:12 <pulpbot> dralley has joined triage 14:31:16 <ttereshc> !next 14:31:17 <pulpbot> 3 issues left to triage: 2734, 2745, 2747 14:31:18 <ttereshc> #topic cancelling task does not update task group - http://pulp.plan.io/issues/2734 14:31:18 <pulpbot> Pulp Issue #2734 [NEW] (unassigned) - Priority: Normal | Severity: Medium 14:31:18 <pulpbot> cancelling task does not update task group - http://pulp.plan.io/issues/2734 14:31:20 <bmbouter> !here 14:31:20 <bmbouter> #info bmbouter has joined triage 14:31:21 <pulpbot> bmbouter has joined triage 14:31:29 <pcreech> !here 14:31:29 <pcreech> #info pcreech has joined triage 14:31:29 <pulpbot> pcreech has joined triage 14:31:37 <ttereshc> beav ok, thnaks for the heads up 14:31:53 <asmacdo> !here 14:31:53 <asmacdo> #info asmacdo has joined triage 14:31:54 <pulpbot> asmacdo has joined triage 14:32:06 <dkliban> we should skip again then 14:32:06 <mhrivnak> skip for now? 14:32:07 <ttereshc> I was not able to reproduce the issue with 2.8.7 as well but since beav will look into it, skip? 14:32:11 <bmbouter> skip yes 14:32:13 <ttereshc> !propose skip 14:32:13 <ttereshc> #idea Proposed for #2734: Skip this issue for this triage session. 14:32:13 <pulpbot> Proposed for #2734: Skip this issue for this triage session. 14:32:18 <ttereshc> !accept 14:32:18 <ttereshc> #agreed Skip this issue for this triage session. 14:32:18 <pulpbot> Current proposal accepted: Skip this issue for this triage session. 14:32:19 <pulpbot> 2 issues left to triage: 2745, 2747 14:32:19 <ttereshc> #topic Error for a specific rpm is silently skipped during sync with immediate policy - http://pulp.plan.io/issues/2745 14:32:20 <pulpbot> RPM Support Issue #2745 [NEW] (unassigned) - Priority: Normal | Severity: Medium 14:32:20 <pulpbot> Error for a specific rpm is silently skipped during sync with immediate policy - http://pulp.plan.io/issues/2745 14:32:47 <jortel> !here 14:32:47 <jortel> #info jortel has joined triage 14:32:48 <pulpbot> jortel has joined triage 14:32:51 <ttereshc> this one is for error handling only so I suggest 14:32:55 <ttereshc> !propose accept 14:32:55 <ttereshc> #idea Proposed for #2745: Leave the issue as-is, accepting its current state. 14:32:55 <pulpbot> Proposed for #2745: Leave the issue as-is, accepting its current state. 14:33:23 <daviddavis> !here 14:33:23 <daviddavis> #info daviddavis has joined triage 14:33:24 <pulpbot> daviddavis has joined triage 14:34:16 <mhrivnak> +1 14:34:16 <daviddavis> what's the correct behavior? continue sync if there's an error or error out? 14:34:31 <mhrivnak> That's been much-debated. :) 14:34:44 <mhrivnak> The established behavior is to continue and get as much as you can. 14:34:48 <ttereshc> we can discuss it on the issue but the behavior should be consistent anyway I think 14:35:15 <daviddavis> agreed 14:35:25 <daviddavis> +1 to accept 14:35:26 <ttereshc> !accept 14:35:26 <ttereshc> #agreed Leave the issue as-is, accepting its current state. 14:35:26 <pulpbot> Current proposal accepted: Leave the issue as-is, accepting its current state. 14:35:27 <pulpbot> 1 issues left to triage: 2747 14:35:28 <ttereshc> #topic RPM exceeds mongo document size limit if its filelist > ~15MB - http://pulp.plan.io/issues/2747 14:35:28 <pulpbot> RPM Support Issue #2747 [NEW] (unassigned) - Priority: Normal | Severity: Medium 14:35:28 <pulpbot> RPM exceeds mongo document size limit if its filelist > ~15MB - http://pulp.plan.io/issues/2747 14:35:48 <dkliban> this should be high priority 14:36:36 <bmbouter> I think we either accept and fix by using GridFS or we close as WONTFIX 14:36:37 <ttereshc> I am not sure, we discussed it last time that to fix it properly it may be too big of a change... though I'd love to see this fixed 14:37:14 <mhrivnak> I think we all want it fixed. It's a matter of fixing it now with a big new effort on pulp 2, or focus on pulp 3 and fix it there. 14:37:14 <dkliban> we will continue seeing users hit this problem 14:37:51 <ttereshc> current limitation is parsed filelist, what do we use it for? search? 14:38:00 <bmbouter> I think we use this https://docs.mongodb.com/manual/core/gridfs 14:38:05 <mhrivnak> I suspect it doesn't get used at all. 14:38:23 <bmbouter> but it's still part of the API so it's covered by semver 14:38:24 <mhrivnak> And was just added to the model ages ago "in case". 14:38:54 <ttereshc> then maybe we can look at it and remove? it will significantly low chances to hit the issue 14:38:56 * pcreech wonders why filelist is stored in the db 14:39:14 <ttereshc> because then, only gzipped metadata will exist 14:39:17 <bmbouter> it's because we slice/dice/store the xml in our database 14:39:33 <mhrivnak> This one is not actually related to the XML. 14:39:38 <mhrivnak> although it's a similar problem. 14:39:48 <pcreech> this is the specific rpm's file list, no? 14:40:00 <mhrivnak> Correct. 14:40:01 <bmbouter> yes (I thought it was xml but maybe not) 14:40:09 <mhrivnak> The file list gets stored twice on the modle. 14:40:15 <ttereshc> yeah, xml is in a good shape now as far as it could be 14:40:15 <mhrivnak> Once in XML form, and once in this list form. 14:40:24 * pcreech wonders how inefficient it would be to just read it from rpm on disk when needed 14:40:39 <mhrivnak> wouldn't work for on-demand :( 14:40:51 <mhrivnak> good thought though. 14:41:00 <bmbouter> for Pulp3 I'm hoping we can use createrepo_c to do all the metadata (even with on_demand)_ 14:41:09 <bmbouter> but that is a separate convo altogether 14:41:12 <jortel> ttereshc: no, bz. did you file this on behalf of a community user? 14:41:39 <ttereshc> jortel, no we just found this issue with oVirt repo on our own 14:41:40 <pcreech> sidecomment: with proper normalization and FK support, we could store it in the db in p3 easily 14:41:44 <bmbouter> there should be a BZ probably b/c oVirt can't be sync'd 14:42:26 <bmbouter> so I'm conflicted on fixing this 14:42:45 <ttereshc> !propose other look if filelists can be removed or close as wontfix 14:42:45 <ttereshc> #idea Proposed for #2747: look if filelists can be removed or close as wontfix 14:42:46 <pulpbot> Proposed for #2747: look if filelists can be removed or close as wontfix 14:42:51 <mhrivnak> Me too. It's not clear that it's causing much pain for anyone. 14:43:01 <jortel> agreed 14:43:16 <dkliban> mhrivnak: but it is keeping some potential pulp users from using Pulp. oVirt team in particular 14:43:16 <bmbouter> not being able to sync a major upstream project is not ok 14:43:50 <mhrivnak> Agreed. I think we all want to fix it. It's just a matter of pulp 2 vs 3. 14:43:56 <bmbouter> yes, I am also conflicted 14:44:08 <pcreech> Yes, i'm concerned about ability to sync ovirt, and long filelists with nodejs stuff is probably common. Probably investigation on a fix for pulp2 would help here 14:44:09 <bmbouter> how is this related to the gzip? 14:44:12 <dkliban> let's discuss post triage 14:44:12 <pcreech> so +1 to proposed 14:44:40 <ttereshc> bmbouter, it is unrelated, we gave more room for parsed filelists, that's it 14:45:07 <ttereshc> !propose other triage normal/medium and look if filelists can be removed or close as wontfix 14:45:07 <ttereshc> #idea Proposed for #2747: triage normal/medium and look if filelists can be removed or close as wontfix 14:45:07 <pulpbot> Proposed for #2747: triage normal/medium and look if filelists can be removed or close as wontfix 14:45:18 <bmbouter> are we adding to sprint? 14:45:26 <jortel> I hope not 14:45:27 <bmbouter> or no? (again I'm conflicted) 14:45:35 <dkliban> let's not add to the sprint 14:45:39 * pcreech thinks it can wait 14:45:45 <dkliban> but i do want more discussion on pulp-dev 14:45:51 <ttereshc> yeah, no complains froma single user so far 14:46:12 <ttereshc> any objections for a proposal ^? 14:46:22 <bmbouter> I still think we should consider using gridFS to store the filelists 14:46:28 <bmbouter> the proposal says either delete or wontfix 14:46:35 <ttereshc> yes 14:47:17 <jortel> I say we defer to pulp3 unless we get a high prio bz or push from community. 14:47:24 <bmbouter> ~propose other triage normal/medium and discuss on pulp-dev, potentially close as wontfix 14:47:34 <bmbouter> the issue jortel is that oVirt can't use pulp2 with this issue 14:47:49 <ttereshc> !propose other triage normal/medium and discuss on pulp-dev, potentially close as wontfix 14:47:49 <ttereshc> #idea Proposed for #2747: triage normal/medium and discuss on pulp-dev, potentially close as wontfix 14:47:49 <pulpbot> Proposed for #2747: triage normal/medium and discuss on pulp-dev, potentially close as wontfix 14:47:55 <mhrivnak> +1 14:48:04 <bmbouter> I agree defering to pulp3 ccan still be good 14:48:09 <ttereshc> !accept 14:48:09 <ttereshc> #agreed triage normal/medium and discuss on pulp-dev, potentially close as wontfix 14:48:09 <pulpbot> Current proposal accepted: triage normal/medium and discuss on pulp-dev, potentially close as wontfix 14:48:11 <pulpbot> No issues to triage. 14:48:15 <bmbouter> but it's kind of a chicken and egg issue in terms of the push from the community 14:48:20 <ttereshc> !end 14:48:20 <ttereshc> #endmeeting