| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-25 | |||
| 18:05:32 | mriedem | unless you guys in rhosp are going to backport a feature | |
| 18:05:44 | gregwork | for great justice! | |
| 18:06:09 | sean-k-mooney | we cant backport object changes downstream so that must mean that only the flaovr bassed option was suported in queens downstream | |
| 18:06:16 | sean-k-mooney | i did not check if the full feature was there | |
| 18:08:24 | openstackgerrit | Boris Bobrov proposed openstack/nova master: Set iommu driver for virtio controllers too https://review.opendev.org/684825 | |
| 18:22:21 | sean-k-mooney | mriedem: just responeded on https://review.opendev.org/#/c/683437 | |
| 18:23:14 | sean-k-mooney | its close i have one nit but its not overtly worng but there is a subtle point i noted on ptachset 3 | |
| 18:39:11 | mriedem | efried_rollin: i'm going to try to write a functional recreate test for https://bugs.launchpad.net/nova/+bug/1841481 since the fix(es) involved are pretty hairy | |
| 18:39:11 | openstack | Launchpad bug 1841481 in OpenStack Compute (nova) "Race during ironic re-balance corrupts local RT ProviderTree and compute_nodes cache" [Medium,In progress] - Assigned to Eric Fried (efried) | |
| 18:40:14 | openstackgerrit | Dustin Cowles proposed openstack/nova master: Use SDK for add/remove instance info from node https://review.opendev.org/659691 | |
| 18:40:14 | openstackgerrit | Dustin Cowles proposed openstack/nova master: Use SDK for getting network metadata from node https://review.opendev.org/670213 | |
| 18:48:49 | mriedem | dustinc: the blueprint on those changes is going to have to be updated for ussuri | |
| 18:48:58 | mriedem | in case you haven't re-proposed the spec and added a new blueprint | |
| 18:49:09 | mriedem | call it openstacksdk-in-nova-ussuri | |
| 18:55:11 | openstackgerrit | Merged openstack/nova master: Log error when volume validation fails during boot from volume https://review.opendev.org/684140 | |
| 18:55:17 | openstackgerrit | Merged openstack/nova master: Add functional tests for [cinder]/cross_az_attach=False https://review.opendev.org/684141 | |
| 19:21:27 | efried | mriedem: Are we considering that (ironic rebalance snafu) an RC candidate? | |
| 19:22:21 | mriedem | no, it's a regression since at least queens | |
| 19:27:32 | efried | mriedem: what's top priority to get merged today? | |
| 19:27:46 | efried | or approved today, anyway. Merging might take a couple weeks | |
| 19:28:07 | ozzzo | I'm building a new OS cluster and the boxes all have the same CPU including microcode, but they update to the latest microcode when they reboot. If I set cpu_mode to host-passthrough what will happen when microcode updates? Will VMs built on older microcode be able to migrate to HV with newer? | |
| 19:28:32 | ozzzo | or do I need to disable updating of microcode, if I want to run host-passthrough? | |
| 19:29:53 | efried | ozzzo: I think that kind of question is better for the #openstack channel. This one is for development. | |
| 19:30:09 | ozzzo | nobody answers questions in #openstack | |
| 19:30:20 | ozzzo | not even to refer you to another channel | |
| 19:30:28 | ozzzo | questions are answered with silence | |
| 19:30:38 | efried | oh | |
| 19:30:40 | efried | that's a pity | |
| 19:30:46 | ozzzo | so I am trying other #openstack-* channels | |
| 19:30:54 | efried | sean-k-mooney, kashyap: that question ---^ seems like it might be in your wheelhouse? | |
| 19:31:03 | mriedem | kashyap has a summit talk about this, trying to find it | |
| 19:31:38 | mriedem | https://docs.openstack.org/nova/latest/admin/configuration/hypervisor-kvm.html#specify-the-cpu-model-of-kvm-guests | |
| 19:31:40 | efried | well, at least I was right about something :P | |
| 19:31:50 | mriedem | https://www.openstack.org/videos/summits/berlin-2018/effective-virtual-cpu-configuration-in-nova | |
| 19:32:13 | mriedem | efried: i think the immediate priority is just the prelude and dependent docs | |
| 19:32:19 | mriedem | https://etherpad.openstack.org/p/nova-train-release-todo | |
| 19:32:40 | ozzzo | ok I'll watch that, ty! | |
| 19:32:45 | efried | ack; I just approved the pcpu doc (sean-k-mooney hope that's okay, anything else can be fupped?). Not sure what to do about the vpmem doc | |
| 19:32:53 | sean-k-mooney | ozzzo: no libivrt checks that the microcode matach when you use host-passthough but i belive it also does that for host-model | |
| 19:33:39 | efried | I'd be willing to +2 despite having my fingers in it, but definitely want another (non-Intel) core. It looks like stephenfin didn't get back to it today... | |
| 19:33:40 | sean-k-mooney | ozzzo: kashyap might be able to clarify that. | |
| 19:34:03 | mriedem | sean-k-mooney: what happened to your birthday? | |
| 19:34:05 | efried | ozzzo: fyi, kashyap is euro timezone (belgium I think) in case you want to stalk him earlier in the day | |
| 19:34:27 | efried | all birthdays are suspended pending RC1 | |
| 19:34:30 | sean-k-mooney | efried: ya as i said i have one nit that i noted on ps3 were its not quite correct but its better then it was and it can be fixed up later | |
| 19:34:37 | ozzzo | I watched kashyap's video last week when I was figuring out which cpu_mode I wanted. Unless I missed something, he doesn't specifically address what will happen when microcode updates | |
| 19:35:01 | ozzzo | if microcode updates won't ruin live migration, then I definitely want to use host-passthrough | |
| 19:35:14 | sean-k-mooney | the check is done by libvirt not nova | |
| 19:35:20 | ozzzo | even if they will, I still want to use it, if I can disable upgrade | |
| 19:35:26 | sean-k-mooney | for host-passthough i belive libvirt will require they are the same | |
| 19:35:38 | sean-k-mooney | for host model i am not sure | |
| 19:36:05 | ozzzo | I guess I should do an experiment | |
| 19:37:15 | sean-k-mooney | mriedem: i have a beer chilling in the fridge and im about to go play a game on my other monitors so im not really working at the momemt other then chating on irc | |
| 19:37:39 | sean-k-mooney | but i also wont really be paying attention to irc shortly either | |
| 19:38:06 | ozzzo | oic kashyap is here, nice | |
| 19:38:27 | ozzzo | I'll ask him tomorrow morning | |
| 19:54:40 | dustinc | mriedem: Thanks for heads up regarding bp, the spec was reintroduced but with same/old bp. (https://review.opendev.org/#/c/680471/). How do I find the old bp to use it for reference? I search here and it does not show up: https://blueprints.launchpad.net/openstack?searchtext=openstacksdk-in-nova | |
| 19:55:11 | dustinc | oops ignore that, I was mixing links | |
| 19:55:35 | dustinc | been bouncing back and forth between two things, found the bp | |
| 19:58:18 | mriedem | rps | |
| 19:58:22 | mriedem | oops | |
| 19:58:25 | mriedem | https://blueprints.launchpad.net/nova/+spec/openstacksdk-in-nova | |
| 19:58:42 | mriedem | yeah so the spec should be re-proposed for ussuri with the new openstack-sdk-in-nova-ussuri blueprint | |
| 19:59:20 | mriedem | https://specs.openstack.org/openstack/nova-specs/readme.html#previously-approved-specifications | |
| 20:05:58 | dustinc | ok i will check that out, basically I just want to update the bp with what has already been done and clarify what is still left? | |
| 20:06:42 | dustinc | and then reintroduce spec per the readme link you posted? | |
| 20:06:52 | mriedem | efried: ok i think i have a recreate on that ironic rebalance race bug, it's pretty hairy but it does the job i think | |
| 20:13:37 | efried | mriedem: we can do "previously approved" with continuation bps? | |
| 20:14:41 | mriedem | i don't really see why not | |
| 20:14:56 | dustinc | mriedem: I am reading this but still a bit confused regarding what I need to do with the bp itself, do I need to register a new bp as well? https://specs.openstack.org/openstack/nova-specs/readme.html#previously-approved-specifications | |
| 20:16:05 | dustinc | https://wiki.openstack.org/wiki/Blueprints#Spec_.2B_Blueprints_lifecycle | |
| 20:23:14 | mriedem | dustinc: yes | |
| 20:23:27 | dustinc | thanks | |
| 20:23:54 | mriedem | dustinc: register a new blueprint called openstacksdk-in-nova-ussuri, the description should just link to https://blueprints.launchpad.net/nova/+spec/openstacksdk-in-nova and say something to the effect of it's continuing the work started in the train release | |
| 20:24:28 | mriedem | as for re-proposing the spec, you'll copy specs/train/approved/openstacksdk-in-nova.rst to specs/ussuri/approved/openstacksdk-in-nova-ussuri.rst | |
| 20:25:04 | mriedem | that's a bit different from https://specs.openstack.org/openstack/nova-specs/readme.html#previously-approved-specifications because the name changes - i think this is the first time we've had a multi-release continuation blueprint thing like this for specs | |
| 20:25:07 | mriedem | so it's different and weird | |
| 20:25:25 | mriedem | when efried did the ksa-ification there was a spec so i don't remember what he did between releases | |
| 20:25:35 | mriedem | we might have just never completed the blueprint until that work was done, idk | |
| 20:26:29 | efried | Personally I really don't care how we track it. We already marked the current bp complete for Train, but... is it possible to un-mark it and instead push it to ussuri? | |
| 20:27:08 | efried | I marked it complete because we completed part of the work, and I figured we would want a new proposal for ussuri that describes what we got done, what we're going to do next, and what, if anything, has changed about the roadmap. | |
| 20:27:27 | efried | but that's more a statement of the spec than the bp | |
| 20:29:36 | efried | dustinc, mriedem: yeah, that seemed to work fine https://blueprints.launchpad.net/nova/+spec/openstacksdk-in-nova | |
| 20:29:41 | efried | so just reuse the same bp dustinc ^ | |
| 20:30:26 | efried | but I think the new spec should differ as noted, so probably not a fast-approval thing. | |
| 20:30:35 | efried | but still should be fairly trivial. | |
| 20:31:41 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional recreate test for bug 1841481 https://review.opendev.org/684840 | |
| 20:31:41 | openstack | bug 1841481 in OpenStack Compute (nova) "Race during ironic re-balance corrupts local RT ProviderTree and compute_nodes cache" [Medium,In progress] https://launchpad.net/bugs/1841481 - Assigned to Eric Fried (efried) | |
| 20:31:42 | mriedem | efried: ^ hopefully with all of the comments that is clear enough | |
| 20:31:54 | efried | ack | |
| 20:32:08 | mriedem | efried: for multi-release things we usually mark the bp as partially complete | |
| 20:32:15 | mriedem | and then create a new bp with the -<new release> | |
| 20:32:18 | mriedem | like with mox removal | |
| 20:32:24 | efried | yeah | |
| 20:32:41 | efried | Where/how/why does it matter which way we do it? | |
| 20:32:49 | efried | aka "who cares?" | |
| 20:33:02 | mriedem | idk that it does all that much, you'll just be carrying that spec forward for a long time potentially | |
| 20:33:17 | mriedem | but that's what you did with ksa-ification i think | |
| 20:33:33 | efried | which still isn't complete, really :( | |
| 20:33:49 | mriedem | cinder was the only one not done wasn't it? or also barbican/castellan? | |