Earlier  
Posted Nick Remark
#openstack-nova - 2019-09-25
17:57:53 gregwork we are doing a prod rollout so the business decision was to stick with LTS releases
17:58:04 gregwork so 14 and 15 dont exist as options for us sadly
17:58:18 mriedem sean-k-mooney: train https://review.opendev.org/#/c/579897/
17:58:25 sean-k-mooney unfortunetly you are not the only customer with that view
17:59:02 sean-k-mooney oh so it was. it felt recent but i did not think it was train
17:59:42 sean-k-mooney mriedem: we ended up treating this as a bug. is it a candiate for upstream backport? generally i would assume not but it does not hurt to ask
17:59:54 gregwork im debating trying to patch this myself and splice it in /var/lib/config-data/puppet-generated/nova_libvirt and see if i can get the hyperv processor bits to die
18:00:12 gregwork then maybe circle back with an rfe
18:04:33 mriedem sean-k-mooney: exhibit A https://review.opendev.org/#/c/663616/
18:05:09 mriedem either way the hide_hypervisor_id stuff upstream was in rocky so gregwork doesn't have it anyway
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 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: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:40:14 openstackgerrit Dustin Cowles proposed openstack/nova master: Use SDK for getting network metadata from node https://review.opendev.org/670213
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: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 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:41 openstackgerrit Matt Riedemann proposed openstack/nova master: Add functional recreate test for bug 1841481 https://review.opendev.org/684840
20:31:42 mriedem efried: ^ hopefully with all of the comments that is clear enough
20:31:54 efried ack

Earlier   Later