| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-12 | |||
| 09:40:24 | efried | so | |
| 09:40:24 | efried | and don't need it. | |
| 09:40:27 | bauzas | that will leave the operator a choice between a quick rolling upgrade (and no performance hit) or a slow rolling upgrade with some performance degradation he could estimate | |
| 09:40:30 | efried | I think this is acceptable. | |
| 09:40:49 | bauzas | efried: not really, you opt-in to a sharded world once you use a conf opt | |
| 09:41:09 | bauzas | efried: I'm talking of the opt usage rolling update (sorry indeed) | |
| 09:41:19 | bauzas | ie. upgrade your cloud to Train | |
| 09:41:22 | bauzas | take your time | |
| 09:41:35 | bauzas | once all computes are done, you have two choices | |
| 09:41:51 | bauzas | A/ you have some puppetry that can change options on the fly | |
| 09:42:11 | bauzas | in this case, you don't really need to use some workaround that gives you performance hit | |
| 09:42:20 | efried | stephenfin: propose double query config on or off by default? | |
| 09:42:21 | bauzas | do the option update at some time | |
| 09:42:49 | bauzas | B/ you don't like CMSes or you prefer updating it smoothly for business reasons | |
| 09:43:01 | bauzas | then, you sign-off for a performance hit | |
| 09:43:13 | bauzas | but you'll be sure everything will continue to work | |
| 09:43:17 | bauzas | this sounds reasonable to me | |
| 09:43:30 | bauzas | that said, I trust cdent | |
| 09:43:30 | stephenfin | efried: the previous approach was a boolean - request PCPU or request VCPU - and it defaulted to requesting VCPU to not break upgrades | |
| 09:43:42 | stephenfin | I think the same thing applies here | |
| 09:44:05 | bauzas | if querying a_c isn't really a performance issue, it's just a matter of providing a temporary codepath | |
| 09:44:09 | efried | stephenfin: meaning we want to err on the side of getting hosts, even if it hurts, so default to double query? | |
| 09:44:18 | cdent | as I said, the performance concern is nova-side processing, which can be tested | |
| 09:44:27 | stephenfin | we need to default to double requests otherwise everyone will upgrade, not realize they need to set 'cpu_dedicated_set' on compute nodes, try to boot a pinned instance and fail miserably | |
| 09:44:38 | stephenfin | efried: yup | |
| 09:44:40 | efried | ack | |
| 09:45:02 | stephenfin | I'll work with TripleO at a minimum to make sure that workaround option is enabled on new deployments | |
| 09:45:14 | stephenfin | Can do the same from OSA and kolla too | |
| 09:45:32 | stephenfin | (though I'm not sure Kolla supports configuring hosts for pinned instances etc.) | |
| 09:46:06 | stephenfin | we've got three hours or so before he's up - should be loads of time to shove everything through | |
| 09:46:24 | efried | yeah, except the part where the gate delay is already past 3h | |
| 09:46:32 | stephenfin | :( | |
| 09:46:33 | efried | 3h13m | |
| 09:46:35 | efried | and counting | |
| 09:46:41 | stephenfin | I saw stuff in the queue for 9 hours last night | |
| 09:46:52 | stephenfin | though I may have been misreading things | |
| 09:47:03 | bauzas | stephenfin: wait a sec | |
| 09:47:24 | bauzas | the workaround necessarly has to be enabled *by default* if you don't wanna break users | |
| 09:47:45 | efried | bauzas: "enabled" meaning "double" yah? | |
| 09:47:52 | efried | I think that's what we're suggesting. | |
| 09:48:14 | efried | stephenfin said he's going to work with the deployment projects to make sure they disable it explicitly for *new* deployments | |
| 09:49:25 | stephenfin | bauzas: what efried said | |
| 09:50:20 | stephenfin | for anyone that knows TripleO, that's what we were planning to do with the previous config option too https://review.opendev.org/#/c/681207/ | |
| 09:50:31 | stephenfin | so it can be done | |
| 09:50:48 | efried | are we ready to unblock the bottom of cpu-resources and/or vpmem at this point? Get them queued up... | |
| 09:51:15 | efried | ...does this issue warrant continuing to hold cpu-resources until ready? | |
| 09:56:48 | stephenfin | I'm biased, but I _think_ we're good | |
| 09:57:04 | luyao | efried: for vpmems, I think I'm ready, but not sure stephenfin and sean-k-mooney, still need sean-k-mooney to confirm the xml again | |
| 09:57:24 | stephenfin | The quota issue and the switch over to the try-try again logic were the blockers. The former's resolved and the latter just needs a tweak | |
| 09:57:58 | stephenfin | I've promised luyao I'll sign off on vPMEM today too, so that's pretty much good to go too | |
| 09:58:40 | efried | Okay. I'll unblock cpu-resources and start +Aing. Plenty of time to yank them out of the gate if something goes pear-shaped. | |
| 09:58:41 | efried | And I'll unblock vpmem, ready for your +A stephenfin | |
| 09:59:09 | stephenfin | Cool. Lemme finish reworking this patch and I'll hit that | |
| 10:01:37 | stephenfin | efried, alex_xu, bauzas: bikeshed time - what should the workaround option be called? | |
| 10:02:09 | stephenfin | it's disabling the second request for VCPUs if the instance is pinned | |
| 10:02:25 | stephenfin | disable_second_request_for_pinned_instances sux | |
| 10:02:31 | efried | [workarounds]try_really_hard_to_get_allocation_candidates_for_pinned_instances_but_suffer_a_performance_hit | |
| 10:02:44 | bauzas | sorry folks, was AFK | |
| 10:02:46 | efried | oh, right, reverse of that | |
| 10:02:49 | stephenfin | *do_not_try_... | |
| 10:02:50 | stephenfin | yup | |
| 10:02:51 | efried | yeah | |
| 10:03:25 | efried | hah, I did that the other day | |
| 10:03:31 | bauzas | you don't imagine how a 9yo can yell at you :p | |
| 10:03:39 | efried | my kid: "why are you so late, dad?" | |
| 10:03:43 | efried | me: "because I suck" | |
| 10:04:13 | bauzas | yeah, life of a remottee | |
| 10:04:16 | bauzas | anyway | |
| 10:04:22 | bauzas | for the workaround name, meh | |
| 10:04:37 | bauzas | just provide a clear doc message, that's it | |
| 10:04:51 | stephenfin | disable_fallback_pcpu_query | |
| 10:04:55 | stephenfin | I'm going with that | |
| 10:04:58 | bauzas | cool | |
| 10:04:58 | efried | ++ | |
| 10:05:12 | bauzas | it could be "brexit" | |
| 10:06:06 | cdent | pcpu_backstop | |
| 10:06:30 | bauzas | this ^ | |
| 10:06:40 | efried | gibi, bauzas, sean-k-mooney: if one of you could ack https://review.opendev.org/#/c/671800/34 at some point soon... | |
| 10:06:55 | alex_xu | stephenfin: +1 disable_fallback_pcpu_query | |
| 10:07:08 | bauzas | efried: I was previously +2 | |
| 10:07:15 | bauzas | efried: but lemme look | |
| 10:07:33 | efried | bauzas: I see a +1 at PS33 | |
| 10:07:40 | bauzas | my bad | |
| 10:07:51 | efried | but yes, please +2+W if you're satisfied | |
| 10:08:00 | efried | this is one I wasn't comfortable +2ing myself. | |
| 10:08:37 | efried | hah, don't do that :P | |
| 10:09:28 | bauzas | oh heh, just discovered https://en.wiktionary.org/wiki/Bauza#English | |
| 10:09:32 | bauzas | \o/ | |
| 10:12:08 | bauzas | efried: https://sbauza.wordpress.com/2014/11/14/how-to-compare-2-patchsets-in-gerrit/ | |
| 10:12:22 | bauzas | (FWIW) | |
| 10:12:42 | efried | You're 26887th in the US | |
| 10:13:30 | bauzas | did the president already paid for France? | |
| 10:13:31 | efried | Yeah, if you moved here there would be 90*4* of you | |
| 10:13:44 | stephenfin | I never learned how to use vimdiff | |
| 10:13:53 | efried | afaict the diff from PS33 is negligible, just that one reinstated assertion in two tests | |
| 10:14:11 | bauzas | that's what I saw | |
| 10:14:19 | bauzas | +Wipped | |
| 10:14:43 | bauzas | stephenfin: you don't really need vimdiff | |
| 10:14:45 | efried | thanks bauzas | |
| 10:14:52 | efried | now, who's going to +A the quota one? | |