14:30:34 <asmacdo> #startmeeting Pulp Triage 2016-09-16
14:30:34 <asmacdo> #info asmacdo has joined triage
14:30:35 <pulpbot> Meeting started Fri Sep 16 14:30:34 2016 UTC and is due to finish in 60 minutes.  The chair is asmacdo. 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_09_16'
14:30:35 <pulpbot> asmacdo has joined triage
14:30:38 <jcline> !here
14:30:38 <jcline> #info jcline has joined triage
14:30:39 <pulpbot> jcline has joined triage
14:30:49 <pcreech> !here
14:30:49 <pcreech> #info pcreech has joined triage
14:30:49 <pulpbot> pcreech has joined triage
14:30:56 <dkliban> !here
14:30:56 <dkliban> #info dkliban has joined triage
14:30:57 <pulpbot> dkliban has joined triage
14:31:13 <mhrivnak> !here
14:31:13 <mhrivnak> #info mhrivnak has joined triage
14:31:14 <pulpbot> mhrivnak has joined triage
14:31:16 <ttereshc> !here
14:31:16 <ttereshc> #info ttereshc has joined triage
14:31:17 <pulpbot> ttereshc has joined triage
14:31:39 <asmacdo> !next
14:31:40 <pulpbot> 9 issues left to triage: 2248, 2252, 2253, 2254, 2255, 2256, 2262, 2263, 2264
14:31:41 <asmacdo> #topic metadata file copy results in error 'Content import of FILENAME failed - must be an existing file' - http://pulp.plan.io/issues/2248
14:31:41 <pulpbot> RPM Support Issue #2248 [NEW] (unassigned) - Priority: Normal | Severity: High | Severity: High
14:31:42 <pulpbot> metadata file copy results in error 'Content import of FILENAME failed - must be an existing file' - http://pulp.plan.io/issues/2248
14:31:52 <asmacdo> did anyone talk with jsherrill about this?
14:32:19 <preethi> !here
14:32:19 <preethi> #info preethi has joined triage
14:32:19 <pulpbot> preethi has joined triage
14:32:23 <jsherrill> reading
14:32:41 <ipanova> !here
14:32:41 <ipanova> #info ipanova has joined triage
14:32:42 <pulpbot> ipanova has joined triage
14:33:11 <bmbouter> !here
14:33:11 <bmbouter> #info bmbouter has joined triage
14:33:12 <pulpbot> bmbouter has joined triage
14:33:47 <jsherrill> asmacdo: i had opened it to track the issue, i'm not confident that ipanova's reproducer steps are what the user followed, as they said they had successfully done the copy after step 7, but later on saw the issue
14:34:05 <jsherrill> which lead me to believe there maybe is some outstanding bug
14:34:12 <jsherrill> but its all just conjecture at this point
14:34:30 <fdobrovo> !here
14:34:30 <fdobrovo> #info fdobrovo has joined triage
14:34:30 <pulpbot> fdobrovo has joined triage
14:35:07 <asmacdo> hmm. well we have the ipanova reproducer, even if it wasn't what the user saw. i am thinking we accept it and expand it if we can nail down the user's case?
14:35:08 <ipanova> jsherrill: depends which units have been copied
14:35:43 <asmacdo> !propose accept
14:35:43 <asmacdo> #idea Proposed for #2248: Leave the issue as-is, accepting its current state.
14:35:44 <pulpbot> Proposed for #2248: Leave the issue as-is, accepting its current state.
14:35:57 <asmacdo> (it is normal/high)
14:36:00 <ipanova> jsherrill: if these were units that were added after upgrade, then copy would succeed, or units that before the upgrade have not been copied, but copied after upgrade
14:36:14 <jsherrill> ipanova: its a complete copy every time
14:36:25 <jsherrill> if we're copying repo a to repo b
14:36:28 <jsherrill> we clear out everything in repo b
14:36:32 <jsherrill> and then copy everything from a to b
14:37:08 <ipanova> jsherrill: it would be good if you would fine more details from the user
14:37:15 <ipanova> s/fine/find
14:37:32 <jsherrill> ipanova: which details exactly?
14:37:51 <jsherrill> he's told me what he's done and a timeline of that
14:38:01 <mhrivnak> It seems like we know that the user can get in a state where the file has been deleted from the FS, right? We did a bug fix to prevent that from happening, but are we just missing a way to deal with the mess that may have been created pre-bugfix?
14:38:25 <jsherrill> mhrivnak: what i'm saying is, based on what the user reported, it happened again post-bugfix
14:38:46 <jcline> It seems worthy of a careful audit
14:38:56 <mhrivnak> jsherrill, I see. I suspect the file was already missing, and they just triggered a symptom of that post-upgrade.
14:39:02 <ipanova> jsherrill: so far i do not see any other way how this could happend - just in those exact steps i provided
14:39:19 <jsherrill> right, and the user may be mis-remembering something, thats always possible
14:39:23 <jsherrill> i'm just reporting what they said
14:39:28 <ipanova> jsherrill: exactly
14:39:55 <jsherrill> they were pretty confident in their claims though
14:39:59 <jsherrill> of the timing of things
14:40:19 <asmacdo> i am convinced that we could make this high/high to at least investigate
14:41:03 <jsherrill> mhrivnak: the only reason i suspect this is not the case, is that they claimed the same operation worked fine after the upgrade to 2.8.7
14:41:14 <mhrivnak> jsherrill, gotcha
14:41:28 <jcline> We can't just close bugs because we're pretty sure it's probably fixed, can we? We should at least look into it, right?
14:41:51 <ipanova> jsherrill: maybe it was a newly created repo with feed, then copy would work fine after upgrade
14:42:05 <mhrivnak> jcline, definitely. I don't think anyone is suggesting we close it.
14:42:49 <asmacdo> current proposal is normal/high. does anyone think it needs to be high/high or can we move on?
14:42:55 <mhrivnak> !propose triage high medium
14:42:55 <mhrivnak> #idea Proposed for #2248: Priority: High, Severity: Medium
14:42:55 <pulpbot> Proposed for #2248: Priority: High, Severity: Medium
14:43:16 <mhrivnak> medium severity since there's a workaround that probably works in most cases.
14:43:21 <mhrivnak> but I could be talked into high severity.
14:43:38 <mhrivnak> but am thinking about severity inflation. :)
14:43:43 <asmacdo> I'm fine with that. ipanova?
14:43:44 <ipanova> mhrivnak: please read the last paragraph of my comment on the issue
14:44:21 <mhrivnak> ipanova, I see. At a minimum, making recovery steps more accessible to users could be valuable.
14:44:28 <ipanova> agree
14:44:39 <mhrivnak> either just on this issue, or in a release note, troubleshooting docs, etc.
14:44:49 <ipanova> +1
14:45:10 <asmacdo> !accept
14:45:10 <asmacdo> #agreed Priority: High, Severity: Medium
14:45:10 <pulpbot> Current proposal accepted: Priority: High, Severity: Medium
14:45:12 <asmacdo> #topic Repo sync with "epoch" related error message. - http://pulp.plan.io/issues/2252
14:45:12 <pulpbot> 8 issues left to triage: 2252, 2253, 2254, 2255, 2256, 2262, 2263, 2264
14:45:12 <pulpbot> RPM Support Issue #2252 [NEW] (unassigned) - Priority: Normal | Severity: Medium | Severity: Medium
14:45:13 <pulpbot> Repo sync with "epoch" related error message. - http://pulp.plan.io/issues/2252
14:46:09 <mhrivnak> This one is pretty crazy. As bmbouter pointed out, it seems like they must have bad data in the DB.
14:46:10 <bmbouter> I think this is another data quality issue (as I wrote on it)
14:46:22 <ipanova> seems like that
14:46:37 <mhrivnak> This user was running manual mongo update commands in the mongo shell trying to solve other issues.
14:46:44 <mhrivnak> So it's at least possible that something went wrong there.
14:46:44 <ipanova> shall we defer that till next triage and have some feedback?
14:47:03 <bmbouter> the commands he ran were given by ipanova and I
14:47:15 <bmbouter> and he has a backup
14:47:21 <ipanova> yeah, those commands had nothing to do with epoch deletion field
14:47:34 <bmbouter> we can defer or accept it I'm ok with either
14:47:48 <mhrivnak> bmbouter, indeed. I saw them and they looked totally sane. But it's still possible he had a copy-paste error, tried some of his own commands, or who knows.
14:47:49 <bmbouter> some info from him would be good and a script can probably be written
14:48:06 <smyers> ipanova++
14:48:06 <pulpbot> ipanova's karma is now 23
14:48:08 <smyers> !propose needinfo
14:48:08 <smyers> #idea Proposed for #2252: This issue cannot be triaged without more info.
14:48:08 <smyers> #info smyers has joined triage
14:48:09 <pulpbot> smyers has joined triage
14:48:10 <pulpbot> Proposed for #2252: This issue cannot be triaged without more info.
14:48:35 <ipanova> +1
14:48:41 <mhrivnak> works for me.
14:48:44 <fdobrovo> +1
14:48:47 <bmbouter> +1
14:48:48 <asmacdo> !accept
14:48:48 <asmacdo> #agreed This issue cannot be triaged without more info.
14:48:49 <pulpbot> Current proposal accepted: This issue cannot be triaged without more info.
14:48:50 <asmacdo> #topic pulp status call hangs if qpid is unresponsive - http://pulp.plan.io/issues/2253
14:48:50 <pulpbot> 7 issues left to triage: 2253, 2254, 2255, 2256, 2262, 2263, 2264
14:48:51 <pulpbot> Pulp Issue #2253 [NEW] (unassigned) - Priority: Normal | Severity: Medium | Severity: Medium
14:48:52 <pulpbot> pulp status call hangs if qpid is unresponsive - http://pulp.plan.io/issues/2253
14:49:17 <dkliban> this seems like a high/high to me
14:49:22 <bmbouter> agreed
14:49:36 <asmacdo> propose triage high high
14:49:39 <asmacdo> !propose triage high high
14:49:39 <asmacdo> #idea Proposed for #2253: Priority: High, Severity: High
14:49:40 <pulpbot> Proposed for #2253: Priority: High, Severity: High
14:49:48 <mhrivnak> Why high severity?
14:50:04 <dkliban> cause katello relies on that API
14:50:35 <jcline> Yeah this seems important
14:50:54 <pcreech> +1
14:50:59 <mhrivnak> This bug only happens if qpid is already in a bad state. I agree this is quite important, but it comes down to a failure to report other bad state.
14:51:03 <smyers> qpid becomes unresponsive on its own, aiui, and there's no workaround for fixing it unless the pulp admin is able to also control qpid, which isn't guaranteed.
14:51:07 <jcline> Presumably you could also kill the whole system by locking up worker threads, right?
14:51:08 <smyers> Pulp should handle it well.
14:52:04 <asmacdo> mhrivnak, are you satisfied?
14:53:03 <mhrivnak> I'd go with high/medium personally, because fixing this won't change the fact that qpid is broken in that circumstance and everything's borked, but I'm ok with any severity.
14:53:20 <smyers> This hasn't got anything to do with qpid
14:53:26 <smyers> It's about how pulp handles a broken qpid
14:53:49 <smyers> It shouldn't crap its pants entirely when the broker's...er...broken
14:54:00 <jsherrill> from a user perspective of katello, we hit that status api quite a bit before performing an action, so from a user perspective if you want them to try to perform and action and immediate get an error about 'qpid is down' vs the entire system hanging
14:54:00 <mhrivnak> It's only the status API we're talking about, right?
14:54:00 <asmacdo> lol smyers
14:54:15 <smyers> jsherrill++
14:54:15 <pulpbot> jsherrill's karma is now 1
14:54:26 <smyers> only 1? jsherrill needs more love
14:54:43 <asmacdo> !accept
14:54:43 <asmacdo> #agreed Priority: High, Severity: High
14:54:43 <pulpbot> Current proposal accepted: Priority: High, Severity: High
14:54:43 <jsherrill> maybe i can transfer some from other bots
14:54:44 <asmacdo> #topic Distributor options are not documented - http://pulp.plan.io/issues/2254
14:54:44 <pulpbot> 6 issues left to triage: 2254, 2255, 2256, 2262, 2263, 2264
14:54:45 <pulpbot> OSTree Support Issue #2254 [NEW] (unassigned) - Priority: Normal | Severity: Medium | Severity: Medium
14:54:46 <pulpbot> Distributor options are not documented - http://pulp.plan.io/issues/2254
14:54:47 <asmacdo> jsherrill++
14:54:47 <pulpbot> jsherrill's karma is now 2
14:54:49 <mhrivnak> You make a request to the status API and it hangs instead of reporting failure?
14:54:54 <ipanova> jsherrill++
14:54:54 <pulpbot> jsherrill's karma is now 3
14:54:55 <jcline> mhrivnak, if you can lock a thread making a call, imagine what happens when you make lots of calls. You could bring the entire REST API down.
14:54:57 <ipanova> let's share love
14:55:01 <asmacdo> oh sorry mhrivnak would you like to go back?
14:55:02 <jsherrill> mhrivnak: thats what the issue was about
14:55:04 <jcline> jsherrill++
14:55:04 <pulpbot> jsherrill's karma is now 4
14:55:22 <mhrivnak> gotcha, ok. we can move on.
14:55:46 <mhrivnak> jcline, that's a great point. thanks.
14:56:35 <dkliban> lets accept as is
14:56:41 <asmacdo> !propose accept
14:56:41 <asmacdo> #idea Proposed for #2254: Leave the issue as-is, accepting its current state.
14:56:41 <pulpbot> Proposed for #2254: Leave the issue as-is, accepting its current state.
14:57:06 <ttereshc> +1
14:57:08 <fdobrovo> +1
14:57:10 <ipanova> +1
14:57:16 <pcreech> +1
14:57:24 <asmacdo> !accept
14:57:24 <asmacdo> #agreed Leave the issue as-is, accepting its current state.
14:57:25 <pulpbot> Current proposal accepted: Leave the issue as-is, accepting its current state.
14:57:25 <asmacdo> #topic Distributor behaviour is not documented - http://pulp.plan.io/issues/2255
14:57:26 <pulpbot> 5 issues left to triage: 2255, 2256, 2262, 2263, 2264
14:57:27 <pulpbot> OSTree Support Issue #2255 [NEW] (unassigned) - Priority: Normal | Severity: Medium | Severity: Medium
14:57:28 <pulpbot> Distributor behaviour is not documented - http://pulp.plan.io/issues/2255
14:58:13 <asmacdo> !propose accept
14:58:13 <asmacdo> #idea Proposed for #2255: Leave the issue as-is, accepting its current state.
14:58:14 <pulpbot> Proposed for #2255: Leave the issue as-is, accepting its current state.
14:58:18 <mhrivnak> +1
14:58:18 <ipanova> +1
14:58:20 <ttereshc> +1
14:58:24 <fdobrovo> +1
14:58:50 <asmacdo> !accept
14:58:50 <asmacdo> #agreed Leave the issue as-is, accepting its current state.
14:58:50 <pulpbot> Current proposal accepted: Leave the issue as-is, accepting its current state.
14:58:51 <pulpbot> 4 issues left to triage: 2256, 2262, 2263, 2264
14:58:52 <asmacdo> #topic Document cancel_publish_repo for distributors - http://pulp.plan.io/issues/2256
14:58:52 <pulpbot> Pulp Issue #2256 [NEW] (unassigned) - Priority: Normal | Severity: Medium | Severity: Medium
14:58:53 <pulpbot> Document cancel_publish_repo for distributors - http://pulp.plan.io/issues/2256
14:59:07 <ipanova> !propose accept
14:59:07 <ipanova> #idea Proposed for #2256: Leave the issue as-is, accepting its current state.
14:59:08 <pulpbot> Proposed for #2256: Leave the issue as-is, accepting its current state.
14:59:11 <fdobrovo> +1
14:59:14 <pcreech> +1
14:59:30 <ipanova> btw, we use to make a day for docs bug
14:59:39 <ipanova> shall we do that again one day?
14:59:49 <bmbouter> we should
14:59:53 <asmacdo> ipanova++
14:59:53 <pulpbot> ipanova's karma is now 24
15:00:00 <smyers> ipanova++
15:00:00 <pulpbot> ipanova's karma is now 25
15:00:01 <mhrivnak> ipanova, certainly for 3.0 we should if not sooner.
15:00:03 <bmbouter> we have a lot of content problems
15:00:29 <ipanova> +1
15:00:39 <asmacdo> mhrivnak, i think we should have a docs day for the 2.y line before we ditch it
15:01:04 <mhrivnak> ack
15:01:04 <asmacdo> !accept
15:01:04 <asmacdo> #agreed Leave the issue as-is, accepting its current state.
15:01:05 <pulpbot> Current proposal accepted: Leave the issue as-is, accepting its current state.
15:01:06 <asmacdo> #topic Rewrite all shebangs to explicitly call python3 in 3.0-dev - http://pulp.plan.io/issues/2262
15:01:06 <pulpbot> 3 issues left to triage: 2262, 2263, 2264
15:01:07 <pulpbot> RPM Support Issue #2262 [NEW] (unassigned) - Priority: Normal | Severity: Medium | Severity: Medium
15:01:08 <pulpbot> Rewrite all shebangs to explicitly call python3 in 3.0-dev - http://pulp.plan.io/issues/2262
15:01:27 <asmacdo> !propose other switch to task
15:01:27 <asmacdo> #idea Proposed for #2262: switch to task
15:01:28 <pulpbot> Proposed for #2262: switch to task
15:01:35 <mhrivnak> +1
15:01:47 <fdobrovo> +1
15:01:52 <ipanova> +1
15:02:05 <smyers> Woops
15:02:08 <asmacdo> prio normal medium?
15:02:09 <smyers> I thought it was a task :D
15:02:17 <pcreech> ++11
15:02:23 <pcreech> er...
15:02:24 <pcreech> +1
15:02:37 <asmacdo> ppccreeeccchh++++
15:02:38 <smyers> I don'toh god and it's in rpm support
15:02:41 <smyers> was I drunk?
15:02:46 <smyers> oh man
15:03:10 <asmacdo> !accept
15:03:10 <asmacdo> #agreed switch to task
15:03:11 <pulpbot> Current proposal accepted: switch to task
15:03:12 <asmacdo> #topic Fast-forward yum publish skips units if previous publish was cancelled - http://pulp.plan.io/issues/2263
15:03:12 <pulpbot> 2 issues left to triage: 2263, 2264
15:03:13 <pulpbot> RPM Support Issue #2263 [NEW] (unassigned) - Priority: Normal | Severity: High | Severity: High
15:03:14 <pulpbot> Fast-forward yum publish skips units if previous publish was cancelled - http://pulp.plan.io/issues/2263
15:03:49 <mhrivnak> !propose triage high high
15:03:49 <mhrivnak> #idea Proposed for #2263: Priority: High, Severity: High
15:03:49 <asmacdo> is this fixable without transactions?
15:03:49 <pulpbot> Proposed for #2263: Priority: High, Severity: High
15:03:58 <mhrivnak> yes, it should be.
15:04:12 <ttereshc> +1 for high/high
15:04:31 <mhrivnak> It appears the last_published attribute is getting updated in a case where it should not. It should be easy to just not update it.
15:05:09 <asmacdo> !accept
15:05:09 <asmacdo> #agreed Priority: High, Severity: High
15:05:09 <pulpbot> Current proposal accepted: Priority: High, Severity: High
15:05:10 <pulpbot> 1 issues left to triage: 2264
15:05:11 <asmacdo> #topic better error reporting during import/association - http://pulp.plan.io/issues/2264
15:05:11 <pulpbot> Pulp Issue #2264 [NEW] (unassigned) - Priority: Normal | Severity: Medium | Severity: Medium
15:05:12 <ipanova> yes, it should be at easy change
15:05:12 <pulpbot> better error reporting during import/association - http://pulp.plan.io/issues/2264
15:05:16 <ipanova> s/at/an
15:05:41 <mhrivnak> oooo a PR. That's always nice to see.
15:05:48 <bmbouter> yeah it is
15:05:48 <dkliban> we can accept as is. he submitted a PR for this issue, but it still needs to have unit tests fixed
15:05:53 <asmacdo> !propose other switch to story
15:05:53 <asmacdo> #idea Proposed for #2264: switch to story
15:05:54 <pulpbot> Proposed for #2264: switch to story
15:06:00 <ipanova> asmacdo: though i would not accept that for high/high, because there is force full flag
15:06:31 <asmacdo> k ipanova we can go back to 2263 next
15:06:33 <bmbouter> it does change a significant thing though in that 1 line
15:06:50 <bmbouter> we catch Exception and raise PulpCodedException
15:07:32 <bmbouter> so maybe now is an ok time to do that
15:07:50 <bmbouter> we do this all over the codebase
15:08:09 <mhrivnak> I think this can stay as a bug if we're ok thinking of it as "pulp hides a perfectly good error message from the user"
15:08:21 <bmbouter> that sounds good to me
15:08:30 <asmacdo> this one does seem to swallow useful errors more often than other PulpCodedExceptions
15:08:37 <bmbouter> I agree
15:08:41 <asmacdo> !propsoe accept
15:08:41 <pulpbot> Error: "propsoe" is not a valid command.
15:08:42 <bmbouter> ok let's do this
15:08:48 <asmacdo> !proppse accept
15:08:48 <pulpbot> Error: "proppse" is not a valid command.
15:08:53 <bmbouter> yes
15:08:54 <bmbouter> so yes
15:08:55 <mhrivnak> also, it raises a PulpExecutionException, which does not appear ot be a PulpCodedException.
15:08:56 <asmacdo> !propose accept
15:08:56 <asmacdo> #idea Proposed for #2264: Leave the issue as-is, accepting its current state.
15:08:57 <pulpbot> Proposed for #2264: Leave the issue as-is, accepting its current state.
15:09:02 <bmbouter> oh gosh
15:09:12 <bmbouter> well then let's definitly do this
15:09:16 <mhrivnak> +1
15:09:25 <asmacdo> !accept
15:09:25 <asmacdo> #agreed Leave the issue as-is, accepting its current state.
15:09:26 <pulpbot> Current proposal accepted: Leave the issue as-is, accepting its current state.
15:09:27 <pulpbot> No issues to triage.
15:09:29 <mhrivnak> and assign to jluza_
15:09:36 <asmacdo> !issue 2263
15:09:36 <asmacdo> #topic Fast-forward yum publish skips units if previous publish was cancelled - http://pulp.plan.io/issues/2263
15:09:37 <pulpbot> RPM Support Issue #2263 [NEW] (unassigned) - Priority: High | Severity: High | Severity: High
15:09:37 <mhrivnak> :)
15:09:37 <pulpbot> Fast-forward yum publish skips units if previous publish was cancelled - http://pulp.plan.io/issues/2263
15:09:56 <ipanova> so talking about how no-op works, from logical point is correct, because since last publish there were no units added/removed, no config change. so that's why publish says- nothing changed, and that's correct from logical point of view. if you canceled it, you just need to keep in mind to make a force publish
15:10:05 <elyezer> ichimonji10: I've been trying to validate the changes of the python3 branch and I am having connections issues, I will create a sample job to test that on jenkins I think that will be more productive
15:10:16 <elyezer> this is the forth time it fails :(
15:11:17 <ttereshc> ipanova, if it was cancelled you can't say that last_publish occurred at that time
15:11:19 <mhrivnak> Just thinking about the last_publish attribute, it seems reasonable for it to only represent successful publishes.
15:11:22 <ichimonji10> Yeesh. :(
15:11:24 <ttereshc> because it was cancelled)
15:11:34 <dkliban> i am with mhrivnak on this one
15:11:35 <mhrivnak> If a publish was not successful, then the published data did not change.
15:11:51 <asmacdo> what if a publish was partially successful?
15:11:59 <dkliban> asmacdo: there is no such thing
15:12:08 <asmacdo> oh hey, thats good
15:12:10 <mhrivnak> agreed, no such thing.
15:12:31 <ipanova> are sure we do not set the finish_time if publish failed?
15:12:32 <mhrivnak> indeed. :)
15:12:41 <ipanova> if - yes, then, i agree with mhrivnak
15:13:00 <mhrivnak> ipanova, finish_time as in the TaskStatus field?
15:13:31 <ipanova> i think we take the finish_time from task and put it into last_published
15:13:36 <ipanova> but i am not 100% sure
15:13:58 <ipanova> let's investigate that at least but with lower severity
15:14:21 <asmacdo> i can be on board with lower severity than high. the workaround is to force a full publish
15:14:21 <mhrivnak> I think setting finish_time is appropriate, because it can be evaluated within the context of the "state" field.
15:15:33 <asmacdo> !propose triage high medium
15:15:33 <asmacdo> #idea Proposed for #2263: Priority: High, Severity: Medium
15:15:34 <pulpbot> Proposed for #2263: Priority: High, Severity: Medium
15:15:41 <ipanova> mhrivnak: i mean we're taking finished time from task and inject it to the last_publish no matter task was ok or failed. but i might be wrong
15:15:42 <ipanova> +1
15:15:43 <mhrivnak> one quick point...
15:16:01 <mhrivnak> If a user hits this bug, they likely won't realize it.
15:16:13 <mhrivnak> there will be missing packages from their published repo.
15:16:26 <mhrivnak> But unless they're paying close attention, they'll have no idea.
15:16:47 <asmacdo> good point
15:17:04 <mhrivnak> ipanova, you may be right on that. And if that's what pulp is doing, we should change it to only do it if the state was successful.
15:17:04 <ipanova> mhrivnak: sure, but that's why we write release notes
15:17:24 <ipanova> mhrivnak: yes
15:17:25 <ipanova> agreed
15:17:56 <asmacdo> !propose triage high high
15:17:56 <asmacdo> #idea Proposed for #2263: Priority: High, Severity: High
15:17:57 <pulpbot> Proposed for #2263: Priority: High, Severity: High
15:18:00 <mhrivnak> I just don't think release notes are much help when we're talking about missing packages, which are likely to be updates.
15:18:13 <ttereshc> +11
15:18:16 <ttereshc> +1
15:18:48 <ipanova> ok
15:18:50 <mhrivnak> thinking you just published a critical errata and then updated your machines, when actually something was missing without any error message, is potentially dangerous.
15:19:27 <ipanova> maybe will be worth to leave a note about checking if we  update last_publish only with successful one
15:19:41 <mhrivnak> definitely.
15:19:46 <asmacdo> !accept
15:19:46 <asmacdo> #agreed Priority: High, Severity: High
15:19:47 <pulpbot> Current proposal accepted: Priority: High, Severity: High
15:19:48 <pulpbot> No issues to triage.
15:19:52 <asmacdo> ipanova, could you leave that note?
15:19:56 <asmacdo> !end
15:19:56 <asmacdo> #endmeeting