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