15:29:46 <bizhang> #startmeeting Pulp Triage 2016-11-22
15:29:46 <bizhang> #info bizhang has joined triage
15:29:47 <pulpbot> Meeting started Tue Nov 22 15:29:46 2016 UTC and is due to finish in 60 minutes.  The chair is bizhang. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:29:47 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:29:47 <pulpbot> The meeting name has been set to 'pulp_triage_2016_11_22'
15:29:47 <pulpbot> bizhang has joined triage
15:29:50 <mhrivnak> !here
15:29:50 <mhrivnak> #info mhrivnak has joined triage
15:29:51 <pulpbot> mhrivnak has joined triage
15:29:57 <asmacdo> anyone mind if we start with https://pulp.plan.io/issues/2431 ?
15:29:59 <pulpbot> Title: Issue #2431: Potential data corruption - Pulp (at pulp.plan.io)
15:30:08 <bizhang> !2431
15:30:08 <pulpbot> Error: "2431" is not a valid command.
15:30:10 <bmbouter> !here
15:30:10 <bmbouter> #info bmbouter has joined triage
15:30:10 <asmacdo> looks a little scary
15:30:10 <pulpbot> bmbouter has joined triage
15:30:22 <asmacdo> !issue #2431
15:30:22 <pulpbot> Error: '#2431' is not a valid positive integer.
15:30:28 <bizhang> !issue 2431
15:30:29 <smyers> So close
15:30:29 <asmacdo> !issue 2431
15:30:29 <bizhang> #topic Potential data corruption - http://pulp.plan.io/issues/2431
15:30:30 <pulpbot> Pulp Issue #2431 [NEW] (unassigned) - Priority: Normal | Severity: Medium
15:30:31 <pulpbot> Potential data corruption - http://pulp.plan.io/issues/2431
15:30:37 <smyers> asmacdo, you are not the meeting chair
15:30:43 <asmacdo> pulpbot told me
15:30:43 <pulpbot> Error: "told" is not a valid command.
15:30:48 <smyers> I know :)
15:30:49 <asmacdo> lol :)
15:31:16 <asmacdo> anyway, I am just looking at this one and im worried it might be bad?
15:31:32 <smyers> I'm maybe misunderstanding...
15:32:04 <mhrivnak> I appreciate the reproducer, but am now reading a bunch of code to figure out what the bug is.
15:32:11 <smyers> If a user specifies bad metadata, pulp stores it.
15:32:12 <mhrivnak> Anyone have a summary?
15:32:19 <mhrivnak> what is "bad" metadata?
15:32:22 <asmacdo> i think hes saying that he can corrupt the metadata through the user metadata endpoint?
15:32:28 <mhrivnak> hm, ok.
15:32:28 <smyers> that's the part I don't understand
15:32:30 <dkliban> !here
15:32:30 <dkliban> #info dkliban has joined triage
15:32:31 <pulpbot> dkliban has joined triage
15:32:43 <smyers> If you knowing inject bad metadata into pulp, you can break it
15:33:40 <smyers> knowingly. Without a more "real-world" use-case, along the lines of why a user would do this in normal pulp usage (assuming POSTing bad metadata is abnormal), this seems like it maybe isn't a bug.
15:33:49 <smyers> So...I'm maybe misunderstanding. :)
15:33:53 <asmacdo> i think theres an important distinction. if it is the "custom user data" endpoint, permissions might be different than an admin right?
15:34:20 <mhrivnak> Does this reproducer use that endpoint?
15:34:43 <asmacdo> Im not sure but it sounded like that was what he was talking about in the bug
15:35:03 <smyers> I don't see "custom user data" in the bug
15:35:04 <mhrivnak> looks like it's just using the upload API.
15:35:11 <pcreech> url = 'repositories/%s/actions/import_upload/' % REPO_ID
15:35:13 <mhrivnak> I think I understand.
15:35:35 <asmacdo> "user to specify additional metadata"
15:35:41 <asmacdo> I think I took that the wrong way
15:35:42 <mhrivnak> When uploading an RPM, you can optionally specify metadata that will override any values the server side would otherwise introspect.
15:36:03 <asmacdo> im satisfied. do we want to close?
15:36:11 <mhrivnak> http://docs.pulpproject.org/dev-guide/integration/rest-api/content/upload.html#import-into-a-repository
15:36:18 <smyers> I'm thinking needinfo, e.g. "reproducer needs comments and/or bug report needs more detail"
15:36:51 <asmacdo> I think someone on our end should take a closer look at that code and comment
15:37:03 <mhrivnak> I'll comment.
15:37:19 <smyers> !propose needinfo
15:37:19 <smyers> #idea Proposed for #2431: This issue cannot be triaged without more info.
15:37:19 <smyers> #info smyers has joined triage
15:37:20 <pulpbot> smyers has joined triage
15:37:20 <mhrivnak> I think I understand what he's getting at, so I'll ask for clarification along those lines.
15:37:20 <pulpbot> Proposed for #2431: This issue cannot be triaged without more info.
15:37:22 <asmacdo> +1
15:37:43 <smyers> #action mhrivnak will follow up
15:37:47 <pcreech> someone probably should run his reproducer and check first, as it might show the issue better
15:38:02 <mhrivnak> pcreech, ack
15:38:16 <bizhang> sounds like consensus
15:38:18 <bizhang> !accept
15:38:18 <bizhang> #agreed This issue cannot be triaged without more info.
15:38:18 <pulpbot> Current proposal accepted: This issue cannot be triaged without more info.
15:38:19 <pulpbot> 6 issues left to triage: 2427, 2429, 2433, 2434, 2435, 2436
15:38:19 <bizhang> #topic Apache's XSendFile directive causes 404 errors when trying to download rpm packages via HTTP - http://pulp.plan.io/issues/2427
15:38:20 <pulpbot> RPM Support Issue #2427 [NEW] (unassigned) - Priority: Normal | Severity: Medium
15:38:21 <pulpbot> Apache's XSendFile directive causes 404 errors when trying to download rpm packages via HTTP - http://pulp.plan.io/issues/2427
15:38:34 <bizhang> !propose skip
15:38:34 <bizhang> #idea Proposed for #2427: Skip this issue for this triage session.
15:38:35 <pulpbot> Proposed for #2427: Skip this issue for this triage session.
15:38:57 <asmacdo> +1
15:39:07 <pcreech> +1
15:39:09 <mhrivnak> alanoe, ^
15:39:17 <smyers> why skip for triage?
15:39:26 <bizhang> we needsinfoed it last time
15:39:31 <bizhang> and there's no additional info on it
15:39:47 <bmbouter> dkliban tested it and it worked for him which led me to this this was a bug against XSendFile ppc64
15:39:47 <smyers> So we still need info?
15:40:19 <mhrivnak> We could close worksforme
15:40:23 <asmacdo> theresabitofplasticinmyspacebar,brb
15:40:31 <smyers> +1 to worksforme
15:40:54 <bmbouter> dkliban could you also leave a comment with the test you performed to make sure I'm remembering this right
15:41:06 <dkliban> bmbouter: i'll leave a comment
15:41:06 <smyers> ppc is an unsupported arch, so if dkliban or bmbouter could update the issue to reflect it works on a supported arch, I think there's nothing we can do
15:41:14 <smyers> woot
15:41:19 <bmbouter> thx
15:41:22 <mhrivnak> Sounds good.
15:41:33 <smyers> !propose other close notabug
15:41:33 <smyers> #idea Proposed for #2427: close notabug
15:41:34 <pulpbot> Proposed for #2427: close notabug
15:41:50 <bizhang> !accept
15:41:50 <bizhang> #agreed close notabug
15:41:50 <pulpbot> Current proposal accepted: close notabug
15:41:52 <bizhang> #topic repomd.xml in a published yum repository is empty when retrieved via HTTP - http://pulp.plan.io/issues/2429
15:41:52 <pulpbot> 5 issues left to triage: 2429, 2433, 2434, 2435, 2436
15:41:53 <pulpbot> RPM Support Issue #2429 [NEW] (unassigned) - Priority: Normal | Severity: Medium
15:41:54 <mhrivnak> not worksforme?
15:41:54 <pulpbot> repomd.xml in a published yum repository is empty when retrieved via HTTP - http://pulp.plan.io/issues/2429
15:42:08 <mhrivnak> smyers, ?
15:42:11 <smyers> mhrivnak, sorry, I just typed the wrong thing
15:42:19 <mhrivnak> ack
15:42:25 <bizhang> !issue 2427
15:42:26 <bizhang> #topic Apache's XSendFile directive causes 404 errors when trying to download rpm packages via HTTP - http://pulp.plan.io/issues/2427
15:42:26 <pulpbot> RPM Support Issue #2427 [NEW] (unassigned) - Priority: Normal | Severity: Medium
15:42:27 <pulpbot> Apache's XSendFile directive causes 404 errors when trying to download rpm packages via HTTP - http://pulp.plan.io/issues/2427
15:42:32 <smyers> !propose other close worksforme
15:42:32 <smyers> #idea Proposed for #2427: close worksforme
15:42:33 <bizhang> !propose close worksforme
15:42:33 <pulpbot> Proposed for #2427: close worksforme
15:42:34 <pulpbot> Error: "propose" is not a valid command.
15:42:41 <bizhang> !accept
15:42:41 <bizhang> #agreed close worksforme
15:42:42 <pulpbot> Current proposal accepted: close worksforme
15:42:42 <bizhang> #topic repomd.xml in a published yum repository is empty when retrieved via HTTP - http://pulp.plan.io/issues/2429
15:42:43 <pulpbot> 5 issues left to triage: 2429, 2433, 2434, 2435, 2436
15:42:44 <pulpbot> RPM Support Issue #2429 [NEW] (unassigned) - Priority: Normal | Severity: Medium
15:42:45 <smyers> :!
15:42:45 <pulpbot> repomd.xml in a published yum repository is empty when retrieved via HTTP - http://pulp.plan.io/issues/2429
15:43:00 <smyers> sorry 'bout that
15:43:08 <mhrivnak> no worries. :)
15:43:23 <daviddavis> !propose needsinfo
15:43:23 <pulpbot> Error: "propose" is not a valid command.
15:43:41 <smyers> it's needinfo
15:43:44 <bmbouter> +1
15:43:45 <daviddavis> :)
15:43:53 <daviddavis> !propose needinfo
15:43:53 <daviddavis> #idea Proposed for #2429: This issue cannot be triaged without more info.
15:43:53 <daviddavis> #info daviddavis has joined triage
15:43:53 <pulpbot> daviddavis has joined triage
15:43:54 <pulpbot> Proposed for #2429: This issue cannot be triaged without more info.
15:44:11 <mhrivnak> We definitely need more info.
15:44:18 <bizhang> !accept
15:44:18 <bizhang> #agreed This issue cannot be triaged without more info.
15:44:18 <pulpbot> Current proposal accepted: This issue cannot be triaged without more info.
15:44:19 <pulpbot> 4 issues left to triage: 2433, 2434, 2435, 2436
15:44:20 <bizhang> #topic Re-uploading results in old file still being served - http://pulp.plan.io/issues/2433
15:44:20 <pulpbot> Pulp Issue #2433 [NEW] (unassigned) - Priority: Normal | Severity: High
15:44:21 <pulpbot> Re-uploading results in old file still being served - http://pulp.plan.io/issues/2433
15:44:38 <daviddavis> seems like a high priority issue
15:44:54 <daviddavis> errr severity
15:44:58 <mhrivnak> This is an interesting case. The iso plugin perhaps should not allow more than one unit in a repo with the same name.
15:45:23 <mhrivnak> Or add an option to upload to replace any existing files with the same name.
15:45:37 <smyers> yep, similar to rpm duplicate nevra, but likely easier to check since it's a single field and not a combo of 5
15:45:44 <mhrivnak> exactly.
15:46:06 <smyers> !propose triage high high
15:46:06 <smyers> #idea Proposed for #2433: Priority: High, Severity: High
15:46:07 <pulpbot> Proposed for #2433: Priority: High, Severity: High
15:46:09 <smyers> ?
15:46:33 <mhrivnak> smyers, did you note the bottom half of the bug report?
15:46:42 <mhrivnak> what pulp version did the duplicate nevra protection land in?
15:47:03 <smyers> 2.8
15:47:15 <smyers> It's in 2.8.7, specifically
15:47:18 <mhrivnak> Interesting.
15:47:29 <mhrivnak> He seems to be saying it's not.
15:47:31 * mhrivnak shrugs
15:47:40 <mhrivnak> in any case, I think high/high is still fine.
15:48:07 <smyers> I could be wrong, just going from memory on that
15:48:18 <mhrivnak> ack
15:48:40 <asmacdo> +1
15:48:45 <bizhang> !accept
15:48:45 <bizhang> #agreed Priority: High, Severity: High
15:48:45 <pulpbot> Current proposal accepted: Priority: High, Severity: High
15:48:46 <pulpbot> 3 issues left to triage: 2434, 2435, 2436
15:48:46 <bizhang> #topic Add timing output to sync task steps - http://pulp.plan.io/issues/2434
15:48:47 <pulpbot> Pulp Issue #2434 [NEW] (unassigned) - Priority: Normal | Severity: High
15:48:48 <pulpbot> Add timing output to sync task steps - http://pulp.plan.io/issues/2434
15:49:10 <mhrivnak> looks like an RFE
15:49:20 <daviddavis> yea, can't you see the timings in pulp-admin?
15:49:26 <daviddavis> it shows start and finish already
15:49:26 <smyers> this is interesting, and likely related to the previous bug, because it's related to purge_duplicate_nevra being slow on 2.8.7
15:49:40 <mhrivnak> As a user, I want to know how long individual steps in a task took.
15:50:22 <smyers> !suggest convert to story: "As a user, I want to know how long individual steps in a task took"
15:50:22 <smyers> #idea convert to story: As a user, I want to know how long individual steps in a task took
15:50:25 <asmacdo> I think this should be API user only
15:50:30 <asmacdo> no cli
15:50:45 <dkliban> this would be through server.conf changes
15:50:55 <smyers> ?
15:50:58 <dkliban> so it would be done by whoever is running pulp
15:51:01 <mhrivnak> server.conf ?
15:51:48 <dkliban> i was imagining that you couldh ave a setting in server.conf that enables timing for tasks
15:52:08 <dkliban> never mind
15:52:13 <mhrivnak> in pulp 2, the platform can't help with this.
15:52:20 <asmacdo> is it possible to do this now?
15:52:23 <mhrivnak> because each plugin can do whatever it wants with its own progress report.
15:52:29 <asmacdo> can you query task times?
15:52:33 <mhrivnak> yes.
15:52:41 <dkliban> start and finish times
15:52:47 <asmacdo> ah
15:52:54 <mhrivnak> he wants to know how long specific parts of a task took.
15:53:07 <dkliban> yeah ... let's move on to the next issue though
15:53:10 <mhrivnak> So this would be a good fit for pulp 3.
15:53:12 <daviddavis> yea, task steps
15:53:27 <bizhang> would this be low sev since it's an RFE?
15:53:29 <smyers> Yeah, my understanding was timings on individual steps in a task, which...eek
15:53:41 <smyers> But I think it's already in pulp 3, which is nice
15:54:01 <bmbouter> we should close this
15:54:13 <asmacdo> bizhang, when you convert it to a story you will lose the severity drop down
15:54:20 <mhrivnak> bmbouter, is this already in pulp 3?
15:54:32 <bmbouter> the original need was really to investigate a performance problem
15:54:45 <asmacdo> this could be done with a script combined with our api i think
15:54:50 <bmbouter> which is better tracked alredy with https://pulp.plan.io/issues/1939
15:54:52 <pulpbot> Title: Story #1939: As a user, I would like to be able to profile Pulp tasks - Pulp (at pulp.plan.io)
15:55:02 <asmacdo> if we helped them make it it could live in pulp contrib
15:55:07 <smyers> Yeah, I'm surprised this became an rfe for tasking timings, and not a "make purging duplicate nevra less slow" bug.
15:55:09 <bmbouter> yeah we we never know what to time, using the cProfile report is so much better since it has all timings
15:55:37 <bizhang> !propose other close wontfix
15:55:37 <bizhang> #idea Proposed for #2434: close wontfix
15:55:38 <pulpbot> Proposed for #2434: close wontfix
15:55:41 <mhrivnak> hang on
15:55:50 <mhrivnak> I get that this came from a performance investigation.
15:56:05 <mhrivnak> But this request seems distinct. He's asking for timings of steps within a task.
15:56:27 <mhrivnak> Is the argument that we should not do that?
15:56:32 <asmacdo> I think hes asking for a debugging tool
15:56:33 <bmbouter> right but knowing that a step took more time won't help you know why
15:56:54 <mhrivnak> It helps you know where to start digging.
15:57:03 <bmbouter> not that timings are bad necessarily, but I don't think its what he needed
15:57:07 <bmbouter> ehelms: ^?
15:57:23 <mhrivnak> Let's skip, and talk to ehelms about it before dismissing it as not valuable.
15:57:29 <bmbouter> that sounds good
15:57:36 <bizhang> !propose skip
15:57:36 <bizhang> #idea Proposed for #2434: Skip this issue for this triage session.
15:57:36 <pulpbot> Proposed for #2434: Skip this issue for this triage session.
15:57:36 <dkliban> thank you
15:57:41 <bizhang> !accept
15:57:41 <bizhang> #agreed Skip this issue for this triage session.
15:57:41 <pulpbot> Current proposal accepted: Skip this issue for this triage session.
15:57:43 <bizhang> #topic systemd unit file for pulp_streamer tries to start the service before mongod is running - http://pulp.plan.io/issues/2435
15:57:43 <pulpbot> 2 issues left to triage: 2435, 2436
15:57:44 <pulpbot> Pulp Issue #2435 [NEW] (unassigned) - Priority: Normal | Severity: Medium
15:57:45 <pulpbot> systemd unit file for pulp_streamer tries to start the service before mongod is running - http://pulp.plan.io/issues/2435
15:58:24 <mhrivnak> We can't use his proposal because we can't assume that mongo is on the same machine.
15:58:42 <pcreech> Can we add logic in the streamer to start without needing to connect to mongodb?
15:59:16 <pcreech> and then only connect to mongodb when needed?
15:59:30 <smyers> We can do so optionally, which I think is what the bug report provides. Wants vs. Requires
15:59:49 <asmacdo> Is there already restart logic?
16:00:00 <pcreech> but it would fail to start if it couldn't connect to mongodb anyways, no?
16:00:35 <asmacdo> Im betting/hoping that if that happens it sleeps, restarts and then works?
16:00:41 <daviddavis> I think the mongo code retries mongodb for 30s and then gives up
16:00:46 <misa> (fyi, I didn't realize you were triaging, if you need any clarification on https://pulp.plan.io/issues/2431
16:00:48 <pulpbot> Title: Issue #2431: Potential data corruption - Pulp (at pulp.plan.io)
16:01:11 <bmbouter> daviddavis is right, we just tested this
16:01:23 <bmbouter> pymongo itself provides that as the default behavior
16:01:32 <daviddavis> so if mongo doesn't start 30s after pulp_streamer, pulp_streamer just dies
16:02:11 <asmacdo> i think the fix should be to allow users to lengthen that retry amount in their conf
16:02:30 <pcreech> is there a way to move that db connection out of the startup logic and into another section of the code, so the service starts, then tries connecting after running?
16:02:48 <mhrivnak> pcreech, maybe?
16:02:49 <pcreech> so the service itself doesn't die, but it logs errors
16:02:50 <asmacdo> as a user, I can increase the retry connection time of the pulp_streamer
16:03:07 <bmbouter> we can open this but I don't think it's going to be fixed in the 2.y line
16:03:10 <mhrivnak> There is a workaround here for most users at least, that they can use their systemd unit file the way he suggests.
16:03:24 <bmbouter> and in 3.0 we have another bug tracking this functionality for postgresql
16:03:29 <daviddavis> maybe we update the docs then?
16:03:31 <mhrivnak> Since most users do have single-machine deployments.
16:03:39 <bmbouter> +1 to that
16:03:52 <asmacdo> bmbouter, adding a config setting to increase that max retry would be pretty easy right?
16:04:15 <asmacdo> i guess not necessary with the workaround
16:04:23 <asmacdo> im fine with docs update
16:04:52 <bizhang> !suggest document workaround
16:04:52 <bizhang> #idea document workaround
16:05:01 <bizhang> !propose accept
16:05:01 <bizhang> #idea Proposed for #2435: Leave the issue as-is, accepting its current state.
16:05:02 <pulpbot> Proposed for #2435: Leave the issue as-is, accepting its current state.
16:05:07 <asmacdo> +1
16:05:10 <bmbouter> the max timeout addition wouldn't be that hard
16:05:14 <mhrivnak> +1
16:05:18 <mhrivnak> to accepting
16:05:19 <bmbouter> and we'll be doing just that for postgresql anyway
16:05:21 <bmbouter> +1 to accepting
16:05:25 <bizhang> !accept
16:05:25 <bizhang> #agreed Leave the issue as-is, accepting its current state.
16:05:25 <pulpbot> Current proposal accepted: Leave the issue as-is, accepting its current state.
16:05:26 <pulpbot> 1 issues left to triage: 2436
16:05:27 <bizhang> #topic SELinux denial prevents user login - http://pulp.plan.io/issues/2436
16:05:27 <pulpbot> Pulp Issue #2436 [NEW] (unassigned) - Priority: Normal | Severity: High
16:05:28 <pulpbot> SELinux denial prevents user login - http://pulp.plan.io/issues/2436
16:05:31 <smyers> The workaround isn't really a workaround, I think. It's the solution...
16:05:50 <smyers> Nothing actionable in that thought, just saying it out loud
16:06:03 <mhrivnak> smyers, because of multi-machine deploys, I think it's not the solution.
16:06:38 <smyers> I'm saying that putting a custom systemd unit file on the system to match your deployment is the solution. Are you saying it isn't?
16:06:38 <bmbouter> high/high?
16:06:43 <pcreech> If we don't block on db connections, but handle them in another part of the code gracefully, then we won't need to be dependent on them for startup, and can recover easier... but /rant
16:06:44 <asmacdo> do we need want to go back mhrivnak?
16:06:51 <mhrivnak> I guess we should.
16:07:02 <bizhang> !issue 2435
16:07:03 <bizhang> #topic systemd unit file for pulp_streamer tries to start the service before mongod is running - http://pulp.plan.io/issues/2435
16:07:03 <pulpbot> Pulp Issue #2435 [NEW] (unassigned) - Priority: Normal | Severity: Medium
16:07:04 <pulpbot> systemd unit file for pulp_streamer tries to start the service before mongod is running - http://pulp.plan.io/issues/2435
16:07:13 <smyers> I'm just saying...that's not a workaround. That's the actual solution to the bug. Same outcome, in that we should document it.
16:07:29 <mhrivnak> smyers, ok gotcha. I agree that the user should do that for their single-machine deploy, but that still leaves a gap for users who run mongo on a different machine.
16:07:31 <bmbouter> but in a clustered install or when mongod is on a machine other than the service
16:08:31 <bmbouter> and regarding increasing/modifying the timeout, really that won't solve it either what the users are looking for is full retry/reconnect support
16:08:48 <bmbouter> but on the 2.y line for mongod those will likely get closed as WONTFIX
16:08:53 <mhrivnak> also pcreech agreed that the best is to gracefully handle it and wait for a connection, but it may not be worth the effort at this point.
16:09:01 <smyers> Right, that's why I'm saying the docs should make this clear if they don't already, and probably include example for both upstart (ugh) and systemd. All I'm saying is that customizing systemd units for your specific needs is totally normal, and shouldn't be considered a workaround.
16:09:13 <smyers> It's just...a work?
16:09:18 <mhrivnak> smyers, gotcha.
16:09:36 <bmbouter> yeah that sounds fine and we can just doc this limitation
16:09:48 <bmbouter> note also for 3.0 I was tracking this as https://pulp.plan.io/issues/2417
16:09:50 <pulpbot> Title: Task #2417: Ensure all processes have initial and reconnect support for PostgreSQL - Pulp (at pulp.plan.io)
16:10:07 * bmbouter updates that to include pulp_streamer
16:10:20 <bizhang> same action item, different phrasing?
16:10:34 <mhrivnak> I think so.
16:10:38 <smyers> !propose other Alter issue to be about documenting the need to customize local systemd units to fit the deployment needs
16:10:38 <smyers> #idea Proposed for #2435: Alter issue to be about documenting the need to customize local systemd units to fit the deployment needs
16:10:39 <pulpbot> Proposed for #2435: Alter issue to be about documenting the need to customize local systemd units to fit the deployment needs
16:10:41 <smyers> ?
16:10:45 <smyers> words words words
16:10:51 <daviddavis> +1
16:10:55 <bmbouter> +1
16:11:04 <bizhang> !accept
16:11:04 <bizhang> #agreed Alter issue to be about documenting the need to customize local systemd units to fit the deployment needs
16:11:05 <pulpbot> Current proposal accepted: Alter issue to be about documenting the need to customize local systemd units to fit the deployment needs
16:11:05 <mhrivnak> works for me.
16:11:05 <pulpbot> 1 issues left to triage: 2436
16:11:06 <bizhang> #topic SELinux denial prevents user login - http://pulp.plan.io/issues/2436
16:11:06 <pulpbot> Pulp Issue #2436 [NEW] (unassigned) - Priority: Normal | Severity: High
16:11:07 <pulpbot> SELinux denial prevents user login - http://pulp.plan.io/issues/2436
16:11:15 <mhrivnak> ugh
16:11:19 <smyers> So yeah, this was fun
16:11:23 <daviddavis> heh
16:11:40 <smyers> I had a note about this in yesterday's release nots for 2.10.3, because I hadn't looked into wtf was going wrong with the el6 tests
16:11:54 <dkliban> smyers: is this just for el6?
16:11:56 <smyers> But then I did, and hooray more selinux fun on el6
16:12:07 <smyers> dkliban, el7 and fc23+fc24 looked totally normal
16:12:29 <smyers> (so it's just el6)
16:12:32 <dkliban> gotcha
16:12:43 <bmbouter> high/high ?
16:12:48 <dkliban> that's what i am thinking
16:12:59 <smyers> Maybe even urgent/high blocking 2.10.3
16:13:07 <smyers> I don't think we get to release 2.10.3 without this being fixed.
16:13:13 <mhrivnak> agreed.
16:13:15 <dkliban> yeah
16:13:16 <asmacdo> thats probably correct
16:13:17 <smyers> !propose urgent high 2.10.3
16:13:17 <pulpbot> Error: "propose" is not a valid command.
16:13:22 <pcreech> +1
16:13:24 <smyers> WHO WROTE THIS CRAP
16:13:28 <smyers> !propose triage urgent high 2.10.3
16:13:28 <smyers> #idea Proposed for #2436: Priority: Urgent, Severity: High, Target Platform Release: 2.10.3
16:13:29 <pulpbot> Proposed for #2436: Priority: Urgent, Severity: High, Target Platform Release: 2.10.3
16:13:37 <dkliban> smyers: and we did not see this on 2.10.2?
16:13:43 <smyers> s/Target Platform Release/Blocks Release
16:13:51 <smyers> dkliban, we did not, which surprises me
16:14:13 <dkliban> smyers: ok ... i'll take it as assigned
16:14:16 <smyers> 2.10.2 received a pretty high amount of automated and manual testing, with a focus on denials in el6
16:14:45 <dkliban> bizhang: i'll update this issue
16:14:52 <smyers> And pulp-smash absolutely catches this and shows it as a glaring flaw
16:14:52 <bizhang> dkliban, cool
16:15:00 <bizhang> !accept
16:15:00 <bizhang> #agreed Priority: Urgent, Severity: High, Target Platform Release: 2.10.3
16:15:00 <pulpbot> Current proposal accepted: Priority: Urgent, Severity: High, Target Platform Release: 2.10.3
16:15:01 <pulpbot> No issues to triage.
16:15:05 <smyers> (which is how I caught it)
16:15:08 <bizhang> !end
16:15:08 <bizhang> #endmeeting