14:30:42 <ttereshc> #startmeeting Pulp Triage 2017-05-19
14:30:42 <ttereshc> #info ttereshc has joined triage
14:30:43 <pulpbot> Meeting started Fri May 19 14:30:42 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:43 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:30:43 <pulpbot> The meeting name has been set to 'pulp_triage_2017_05_19'
14:30:43 <pulpbot> ttereshc has joined triage
14:30:48 <asmacdo> !here
14:30:48 <asmacdo> #info asmacdo has joined triage
14:30:48 <pulpbot> asmacdo has joined triage
14:30:48 <ipanova> !here
14:30:48 <ipanova> #info ipanova has joined triage
14:30:48 <pulpbot> ipanova has joined triage
14:30:54 <fdobrovo> !here
14:30:54 <fdobrovo> #info fdobrovo has joined triage
14:30:54 <pulpbot> fdobrovo has joined triage
14:31:03 <bizhang> !here
14:31:03 <bizhang> #info bizhang has joined triage
14:31:03 <pulpbot> bizhang has joined triage
14:31:07 <ttereshc> !start
14:31:07 <ttereshc> #info ttereshc has joined triage
14:31:07 <pulpbot> Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
14:31:08 <pulpbot> ttereshc has joined triage
14:31:11 <ttereshc> !next
14:31:13 <ttereshc> #topic _release_resource should be acks_late and idempotent - http://pulp.plan.io/issues/2749
14:31:13 <pulpbot> 7 issues left to triage: 2749, 2758, 2761, 2768, 2769, 2770, 2771
14:31:14 <pulpbot> Pulp Issue #2749 [NEW] (unassigned) - Priority: Normal | Severity: Low
14:31:15 <pulpbot> _release_resource should be acks_late and idempotent - http://pulp.plan.io/issues/2749
14:31:33 <jortel> !heree
14:31:33 <pulpbot> Error: "heree" is not a valid command.
14:31:37 <jortel> !here
14:31:37 <jortel> #info jortel has joined triage
14:31:37 <pulpbot> jortel has joined triage
14:31:43 <ttereshc> bmbouter, skip one more time? ^
14:32:14 <ttereshc> !propose skip
14:32:14 <ttereshc> #idea Proposed for #2749: Skip this issue for this triage session.
14:32:15 <pulpbot> Proposed for #2749: Skip this issue for this triage session.
14:32:16 <bmbouter> yes skip once more I think
14:32:21 <bmbouter> did he respond yet?
14:32:26 <ttereshc> bmbouter, no
14:32:27 <bmbouter> !here
14:32:27 <bmbouter> #info bmbouter has joined triage
14:32:27 <pulpbot> bmbouter has joined triage
14:32:29 <bmbouter> ok then skip
14:32:31 <bmbouter> please
14:32:32 <ttereshc> !accept
14:32:32 <ttereshc> #agreed Skip this issue for this triage session.
14:32:33 <pulpbot> Current proposal accepted: Skip this issue for this triage session.
14:32:34 <ttereshc> #topic Documentation on Pulp's storage logic - http://pulp.plan.io/issues/2758
14:32:34 <pulpbot> 6 issues left to triage: 2758, 2761, 2768, 2769, 2770, 2771
14:32:35 <pulpbot> Pulp Issue #2758 [NEW] (unassigned) - Priority: Normal | Severity: Low
14:32:36 <pulpbot> Documentation on Pulp's storage logic - http://pulp.plan.io/issues/2758
14:32:55 <bmbouter> dkliban is still waiting on a convo w/ this reporter
14:33:06 <ttereshc> !propose skip
14:33:06 <ttereshc> #idea Proposed for #2758: Skip this issue for this triage session.
14:33:07 <pulpbot> Proposed for #2758: Skip this issue for this triage session.
14:33:09 <bmbouter> a time is to talk to get more clarity is still TBD, so +1 skip
14:33:16 <ttereshc> !accept
14:33:16 <ttereshc> #agreed Skip this issue for this triage session.
14:33:16 <pulpbot> Current proposal accepted: Skip this issue for this triage session.
14:33:18 <ttereshc> #topic Iso repo with basic auth does not report sync progress - http://pulp.plan.io/issues/2761
14:33:18 <pulpbot> 5 issues left to triage: 2761, 2768, 2769, 2770, 2771
14:33:20 <pulpbot> RPM Support Issue #2761 [NEW] (unassigned) - Priority: Normal | Severity: Medium
14:33:21 <pulpbot> Iso repo with basic auth does not report sync progress - http://pulp.plan.io/issues/2761
14:33:35 <dkliban> !here
14:33:35 <dkliban> #info dkliban has joined triage
14:33:36 <pulpbot> dkliban has joined triage
14:33:46 <ipanova> it is like that for a long time
14:34:09 <jortel> thomasmckay: the higher the pm score the better for getting it on a sprint.  you can always attend our sprint planning and push for it.  that said, we're aware of its importance and likely get it on a sprint soon.
14:34:22 <ttereshc> ipanova, is it the same issue we looked at recently... due to mongoengine conversion?
14:35:11 <ipanova> ttereshc: i already do not remember much
14:35:17 <ipanova> i suggest low priority
14:35:24 <mhrivnak> +1
14:35:25 <thomasmckay> jortel: PM score is a bugzilla concept, right? so i should make a BZ and push for higher PM?
14:35:58 <ttereshc> !propose triage low low
14:35:58 <ttereshc> #idea Proposed for #2761: Priority: Low, Severity: Low
14:35:58 <pulpbot> Proposed for #2761: Priority: Low, Severity: Low
14:36:02 <mhrivnak> thomasmckay, yes that is a good approach
14:36:09 <ipanova> +1
14:36:14 <ttereshc> !accept
14:36:14 <ttereshc> #agreed Priority: Low, Severity: Low
14:36:14 <pulpbot> Current proposal accepted: Priority: Low, Severity: Low
14:36:16 <thomasmckay> roger that, thanks
14:36:16 <pulpbot> 4 issues left to triage: 2768, 2769, 2770, 2771
14:36:16 <ttereshc> #topic Worker foreign key does not get associated with task in Pulp3 - http://pulp.plan.io/issues/2768
14:36:17 <pulpbot> Pulp Issue #2768 [NEW] (unassigned) - Priority: Normal | Severity: Medium
14:36:17 <jortel> thomasmckay: that story has a related bz already and that is the pm score i am referring to.
14:36:17 <pulpbot> Worker foreign key does not get associated with task in Pulp3 - http://pulp.plan.io/issues/2768
14:36:24 <dalley> !join
14:36:24 <pulpbot> Error: You don't have the admin capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified.
14:36:28 <dalley> !here
14:36:28 <dalley> #info dalley has joined triage
14:36:28 <pulpbot> dalley has joined triage
14:36:52 <mhrivnak> !here
14:36:52 <mhrivnak> #info mhrivnak has joined triage
14:36:53 <pulpbot> mhrivnak has joined triage
14:36:54 <bizhang> This might also be a good sprint candidate
14:37:33 <jortel> yes
14:37:43 <mhrivnak> +1
14:37:43 <bmbouter> wait I think there is some confusion about that field
14:37:54 <asmacdo> i think this must work?
14:38:15 <bmbouter> the worker isn't known until after it's dispatched by the resource manager
14:38:31 <mhrivnak> Good point.
14:38:50 <bmbouter> so if 'when the task is kicked off' means 'by the resource manager' then yes
14:38:53 <mhrivnak> bizhang, does the worker eventually get set? Or are you saying it doesn't get set at all?
14:39:05 <bizhang> mhrivnak, it does not get set at all right now
14:39:09 <bmbouter> if that means when httpd creates the task to start with when it calls apply_async_with_reservation then no
14:39:30 <bizhang> yeah it should be set in apply_async but it isn't
14:39:47 <bmbouter> yeah I can see how this is an issue
14:39:51 <bmbouter> I was looking at this code yesterday
14:40:19 <ttereshc> !propose other triage as-is and add to sprint
14:40:19 <ttereshc> #idea Proposed for #2768: triage as-is and add to sprint
14:40:19 <pulpbot> Proposed for #2768: triage as-is and add to sprint
14:40:21 <bmbouter> we need to remove the part about apply_async_with_reservation since there will be no changes there
14:40:31 <bmbouter> we can put it on the sprint and clean it up after triage
14:40:44 <bmbouter> bizhang: would that be ok w/ you?
14:40:47 <mhrivnak> sounds good.
14:40:54 <bizhang> bmbouter, sounds good. I'll update the description
14:40:56 <asmacdo> wait
14:41:04 <asmacdo> i am almost positive this is working correctly
14:41:22 <asmacdo> the sync task uses the working_dir context manager
14:41:35 <asmacdo> which relies on knowing the worker name
14:41:56 <mhrivnak> follow-up after triage? It can always be closed as worksforme
14:41:59 <dkliban> asmacdo: at run time it knows it...but the DB doesn't have it
14:42:12 <dkliban> i think that's the problem
14:42:24 <ttereshc> +1 to follow-up after triage
14:42:27 <bmbouter> +1 to that
14:42:28 <dkliban> +1
14:42:29 <asmacdo> +1
14:42:29 <ipanova> +1
14:42:30 <bmbouter> also the error is on this line
14:42:31 <ttereshc> !accept
14:42:31 <ttereshc> #agreed triage as-is and add to sprint
14:42:31 <pulpbot> Current proposal accepted: triage as-is and add to sprint
14:42:32 <bmbouter> https://github.com/pulp/pulp/blob/3.0-dev/platform/pulp/tasking/tasks.py#L248
14:42:34 <ttereshc> #topic Relative paths are not checked for collisions - http://pulp.plan.io/issues/2769
14:42:34 <pulpbot> 3 issues left to triage: 2769, 2770, 2771
14:42:35 <pulpbot> Title: pulp/tasks.py at 3.0-dev · pulp/pulp · GitHub (at github.com)
14:42:36 <pulpbot> OSTree Support Issue #2769 [NEW] (unassigned) - Priority: Normal | Severity: Medium
14:42:37 <pulpbot> Relative paths are not checked for collisions - http://pulp.plan.io/issues/2769
14:43:06 <ttereshc> !propose other triage high high and add to sprint
14:43:06 <ttereshc> #idea Proposed for #2769: triage high high and add to sprint
14:43:07 <pulpbot> Proposed for #2769: triage high high and add to sprint
14:43:20 <dkliban> +1
14:43:34 <mhrivnak> +1
14:43:42 <ttereshc> !accept
14:43:42 <ttereshc> #agreed triage high high and add to sprint
14:43:43 <pulpbot> Current proposal accepted: triage high high and add to sprint
14:43:43 <asmacdo> wait again
14:43:44 <ttereshc> #topic Tasks stuck in waiting state if received while qpidd is down - http://pulp.plan.io/issues/2770
14:43:44 <pulpbot> 2 issues left to triage: 2770, 2771
14:43:45 <pulpbot> Pulp Issue #2770 [NEW] (unassigned) - Priority: Normal | Severity: Medium
14:43:46 <pulpbot> Tasks stuck in waiting state if received while qpidd is down - http://pulp.plan.io/issues/2770
14:43:51 <asmacdo> can we go back?
14:43:56 <ttereshc> !issue 2769
14:43:57 <ttereshc> #topic Relative paths are not checked for collisions - http://pulp.plan.io/issues/2769
14:43:57 <pulpbot> OSTree Support Issue #2769 [NEW] (unassigned) - Priority: Normal | Severity: Medium
14:43:58 <pulpbot> Relative paths are not checked for collisions - http://pulp.plan.io/issues/2769
14:44:07 <asmacdo> this is a general problem for all plugins
14:44:20 <mhrivnak> for more than one at least.
14:44:22 <ipanova> asmacdo: it was fixed already in some of the plugings i think
14:44:32 <ttereshc> asmacdo, my understanding that this time it is for ostree
14:44:34 <mhrivnak> Yep, and the bug report calls this a regression.
14:44:44 <ttereshc> and it may be related to the recent ostree PR
14:44:50 <mhrivnak> So apparently it was working in ostree already in the past.
14:44:52 <asmacdo> yes, but can we use a central function to do this checking?
14:44:56 <ttereshc> because this part of code was touched
14:44:58 <ipanova> mhrivnak: it is not a regression, i think it was always like this in ostree plugin
14:45:00 <mhrivnak> asmacdo, maybe we already do?
14:45:13 <ipanova> mhrivnak: because the rel_path collision was fixed just in rpm plugin
14:45:24 <ipanova> as far as i remember
14:45:40 <mhrivnak> asmacdo, I think it's an implementation detail we don't need to hammer out while triaging this issue.
14:45:58 <mhrivnak> Perhaps a comment on the issue would be a good place to raise it?
14:46:16 <asmacdo> well, i think theres an issue
14:46:24 <asmacdo> looking for it
14:46:52 <bmbouter> can we either accept and sort out later or skip?
14:46:53 <ttereshc> let's move on and asmacdo tell me if you want to come back to it at the end of triage
14:46:59 <ttereshc> !next
14:47:01 <ttereshc> #topic Tasks stuck in waiting state if received while qpidd is down - http://pulp.plan.io/issues/2770
14:47:01 <pulpbot> 2 issues left to triage: 2770, 2771
14:47:02 <pulpbot> Pulp Issue #2770 [NEW] (unassigned) - Priority: Normal | Severity: Medium
14:47:03 <pulpbot> Tasks stuck in waiting state if received while qpidd is down - http://pulp.plan.io/issues/2770
14:47:04 <jortel> The PR changed ostree plugin to use the same function for this as RPM.
14:47:23 <bmbouter> mhrivnak: interested to hear if you think accept or accept and add to sprint
14:47:31 <bmbouter> same for all actually: ^
14:47:32 <dkliban> this one sounds bad
14:47:40 <dalley> agreed
14:47:44 <dkliban> and i think we should add to sprint
14:47:49 <bmbouter> yeah we can fix it in one place pretty easily
14:47:51 <ipanova> jortel: if tests for rpm are not failing then maybe there is some issue how it was implemented in ostree?
14:48:07 <bmbouter> so accept and add ot sprint?
14:48:08 <mhrivnak> oh ya, let's fix this ASAP.
14:48:38 <ttereshc> !propose triage high high and add to sprint
14:48:38 <pulpbot> (propose triage <priority> <severity> [target_release]) -- Propose triage values including priority, severity, and an optional target release.
14:48:43 <ttereshc> !propose other triage high high and add to sprint
14:48:43 <ttereshc> #idea Proposed for #2770: triage high high and add to sprint
14:48:44 <pulpbot> Proposed for #2770: triage high high and add to sprint
14:48:48 <bmbouter> +1
14:48:57 <ttereshc> !accept
14:48:57 <ttereshc> #agreed triage high high and add to sprint
14:48:57 <pulpbot> Current proposal accepted: triage high high and add to sprint
14:48:58 <ipanova> +1
14:48:59 <pulpbot> 1 issues left to triage: 2771
14:48:59 <ttereshc> #topic UnicodeEncodeError raised on connecting to a website with latin-1 characters in credentials - http://pulp.plan.io/issues/2771
14:49:00 <pulpbot> Nectar Issue #2771 [NEW] (unassigned) - Priority: Normal | Severity: Medium
14:49:01 <pulpbot> UnicodeEncodeError raised on connecting to a website with latin-1 characters in credentials - http://pulp.plan.io/issues/2771
14:49:30 <ttereshc> user filed it on a github, I just re-filed it in redmine
14:49:45 <jortel> ipanova: perhaps.  hard to say.  the check was broken in ostree so I switched it to use the common utils (bla) function.  I'll need to read the issue and review the test to asses what's going on.
14:50:20 <ipanova> let's triage as it is
14:50:52 <ttereshc> !propose accept
14:50:52 <ttereshc> #idea Proposed for #2771: Leave the issue as-is, accepting its current state.
14:50:52 <pulpbot> Proposed for #2771: Leave the issue as-is, accepting its current state.
14:50:52 <mhrivnak> hm, I wonder why that "encode" is there.
14:51:11 <mhrivnak> works for me.
14:51:19 <mhrivnak> I mean, accepting works for me. :)
14:51:27 <jortel> +1
14:51:29 <ttereshc> :)
14:51:31 <ttereshc> !accept
14:51:31 <ttereshc> #agreed Leave the issue as-is, accepting its current state.
14:51:31 <pulpbot> Current proposal accepted: Leave the issue as-is, accepting its current state.
14:51:32 <pulpbot> No issues to triage.
14:51:47 <ttereshc> asmacdo, do you want to go back to OStree?
14:51:54 <asmacdo> yeah
14:52:03 <asmacdo> i wanted to pitch changing this to a story
14:52:04 <ttereshc> !issue 2769
14:52:04 <ttereshc> #topic Relative paths are not checked for collisions - http://pulp.plan.io/issues/2769
14:52:05 <pulpbot> OSTree Support Issue #2769 [NEW] (unassigned) - Priority: Normal | Severity: Medium
14:52:06 <pulpbot> Relative paths are not checked for collisions - http://pulp.plan.io/issues/2769
14:52:44 <asmacdo> https://github.com/pulp/pulp_rpm/blob/master/plugins/pulp_rpm/plugins/distributors/yum/configuration.py#L494
14:52:45 <pulpbot> Title: pulp_rpm/configuration.py at master · pulp/pulp_rpm · GitHub (at github.com)
14:53:00 <asmacdo> i'd like to move that into core and let all the plugins use it
14:53:52 <mhrivnak> asmacdo, sounds like a refactor.
14:53:58 <ipanova> asmacdo: i se ethis more like refactor
14:54:07 <ipanova> mhrivnak is faster
14:54:21 <ttereshc> right now it is mostly likely regression because tests on a master started to fail, maybe fix ostree issue and file refactor?
14:54:33 <mhrivnak> If there's an active bug, I think we should keep that tracked as an "issue". We could additionally file a refactor.
14:55:03 <ttereshc> I think jortel will make evaluation
14:55:09 <ipanova> actually
14:55:11 <ipanova> asmacdo: https://pulp.plan.io/issues/1106
14:55:11 <ttereshc> I suggest to accept it as a bug for now
14:55:12 <asmacdo> ok, ill leave a comment on the issue
14:55:13 <pulpbot> Title: Issue #1106: relative_path should be checked for url collision - OSTree Support - Pulp (at pulp.plan.io)
14:55:41 <asmacdo> oh hey
14:55:50 <ichimonji10> Issue 1106 is why I've indicated that this relative_path issue is a regression.
14:56:28 <ipanova> then ichimonji10 is right
14:57:01 <ttereshc> !propose other triage high high and add to sprint
14:57:01 <ttereshc> #idea Proposed for #2769: triage high high and add to sprint
14:57:01 <pulpbot> Proposed for #2769: triage high high and add to sprint
14:57:04 <asmacdo> this is why id rather do a refactor
14:57:10 <asmacdo> because this logic is duplicated
14:57:15 <jortel> yeah, I'm looking into this.  the PR change ostree to use this get_repo_distributors_by_relative_url() is some utils module in platform because the impl in ostree was broken and failed on every update.
14:57:37 <jortel> rpm uses this and it /should/ behave the same
14:58:15 <asmacdo> jortel, think we should accept and you can update us later?
14:58:22 <jortel> I need to understand the smash test better.  ichimonji10 can you point me to the smash test?
14:58:26 <ichimonji10> yes
14:58:28 <jortel> yes
14:58:49 <jortel> sorry, I'd assumed it had been accepted :)
14:58:55 <ttereshc> !accept
14:58:55 <ttereshc> #agreed triage high high and add to sprint
14:58:55 <pulpbot> Current proposal accepted: triage high high and add to sprint
14:58:57 <pulpbot> No issues to triage.
14:58:59 <ttereshc> !end
14:58:59 <ttereshc> #endmeeting