| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-29 | |||
| 18:52:32 | openstackgerrit | Mohammed Naser proposed openstack/nova master: Avoid setting MTU if none was configured https://review.openstack.org/614008 | |
| 18:52:44 | mnaser | anyhow | |
| 18:53:00 | cfriesen | ah, that would do it | |
| 18:53:13 | mnaser | thats a fix with the test in the patch above it, i'd be more than happy to iterate if anyone has comments | |
| 18:53:28 | mnaser | considering this has put a big upgrade project to a halt :< | |
| 18:57:26 | mriedem | i'm on a call for the next hour or so but will try to take a look | |
| 18:58:13 | mnaser | cool, thank you, please highlight me if anything so i can iterate | |
| 19:08:50 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Cross-cell resize https://review.openstack.org/603930 | |
| 19:08:50 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add Migration.cross_cell_move and get_by_uuid https://review.openstack.org/614012 | |
| 19:10:21 | cfriesen | mnaser: got a possible problem scenario for you. boot instance on upgraded nova, live-migrate to non-upgraded nova (this will preserve the MTU), then live-migrate back. I suspect the running guest will have MTU, but the generated XML won't. | |
| 19:11:11 | mnaser | cfriesen: isn’t that covered by the _with_mtu test case? | |
| 19:11:28 | mnaser | Where we have a source mtu and it is maintained for the live migration | |
| 19:13:11 | mnaser | It only omits it if the domain XML doesn’t have it, and if the domain XML doesn’t have it then the host_mtu is not set and we’re okay | |
| 19:13:45 | cfriesen | no, in the scenario I just described the running guest would have the MTU, but it's on an older nova that doesn't even try to generate the mtu in the xml | |
| 19:14:05 | cfriesen | unless we actually dump the xml from the running guest, in which case it might be okay | |
| 19:14:25 | cfriesen | can't remember the exact details right now | |
| 19:15:56 | mnaser | cfriesen: I’m assuming in all of this that the XML is being dumped from the running guest | |
| 19:16:22 | mnaser | Let me check | |
| 19:17:06 | cfriesen | yeah, it does. get_xml_desc() in guest.py | |
| 19:19:29 | mnaser | Yup. And it specifies dump_migratable=True | |
| 19:19:55 | mnaser | Which I assume means libvirt will be taking care of not making us do bad things | |
| 19:32:20 | mriedem | mnaser: comments inline | |
| 19:32:21 | mriedem | mostly just nits | |
| 19:36:22 | mriedem | cfriesen: you're talking about this right? https://github.com/openstack/nova/blob/a0eacbf7fff60282007ddca705ef7331e8a4a6f8/nova/virt/libvirt/migration.py#L83 | |
| 19:36:41 | mriedem | yeah that's what i was referring to earlier - before _update_vif_xml we'd just always send the source vif xml unchanged | |
| 19:37:25 | cfriesen | mriedem: yes | |
| 19:44:35 | mnaser | mriedem: cfriesen thanks for the reviews both, i tried to address but in case it wasn't clear in terms of comments, please let me know | |
| 19:44:44 | openstackgerrit | Mohammed Naser proposed openstack/nova master: Add tests for bug #1800511 https://review.openstack.org/614004 | |
| 19:44:44 | openstack | bug 1800511 in OpenStack Compute (nova) "VMs with vif_type bridge/tap started before Rocky upgrade cannot be live migrated" [High,In progress] https://launchpad.net/bugs/1800511 - Assigned to Mohammed Naser (mnaser) | |
| 19:44:44 | openstackgerrit | Mohammed Naser proposed openstack/nova master: libvirt: Avoid setting MTU during live migration if unset https://review.openstack.org/614008 | |
| 19:50:50 | cfriesen | mnaser: much better, one little comment | |
| 19:52:07 | mnaser | cfriesen: i guess i wanted to make sure that a normal reboot wouldn't do the trick (because the qemu-kvm process doesnt get restarted) | |
| 19:52:13 | mnaser | but i guess the follow up comment clears it up | |
| 19:52:47 | openstackgerrit | Mohammed Naser proposed openstack/nova master: libvirt: Avoid setting MTU during live migration if unset https://review.openstack.org/614008 | |
| 19:52:50 | mnaser | cfriesen: voila | |
| 19:52:51 | cfriesen | mnaser: a "nova reboot" without the "hard" option will reset things | |
| 19:52:59 | mnaser | really | |
| 19:53:04 | mnaser | i thought i tried to do an acpi reboot | |
| 19:54:20 | cfriesen | we try an ACPI shutdown | |
| 19:54:31 | cfriesen | then if that doesn't work we do a hard shutdown | |
| 19:54:39 | mnaser | aaaah | |
| 19:54:40 | mnaser | gotcha | |
| 19:54:44 | mnaser | so the reboot always restarts the process | |
| 19:54:54 | mnaser | cool, TIL! | |
| 19:56:11 | mriedem | pep8 is going to fail on https://review.openstack.org/#/c/614004/ | |
| 19:56:57 | mnaser | ah shit | |
| 19:57:42 | mnaser | ill run that locally | |
| 19:58:03 | mriedem | +2 on the top one | |
| 20:21:12 | openstackgerrit | Mohammed Naser proposed openstack/nova master: Add tests for bug #1800511 https://review.openstack.org/614004 | |
| 20:21:12 | openstackgerrit | Mohammed Naser proposed openstack/nova master: libvirt: Avoid setting MTU during live migration if unset https://review.openstack.org/614008 | |
| 20:21:13 | openstack | bug 1800511 in OpenStack Compute (nova) "VMs with vif_type bridge/tap started before Rocky upgrade cannot be live migrated" [High,In progress] https://launchpad.net/bugs/1800511 - Assigned to Mohammed Naser (mnaser) | |
| 20:21:30 | mnaser | mriedem: fixed your nit too if you feel like readding your +2 and cfriesen +1 :) | |
| 20:24:28 | mriedem | +Ws | |
| 20:24:30 | mriedem | oops | |
| 20:24:32 | mriedem | +2s | |
| 20:24:46 | mriedem | time to play the "find another core" game | |
| 20:36:22 | mnaser | mriedem: I guess all the IBM ones are busy today :p | |
| 20:38:34 | mriedem | too soon | |
| 20:42:25 | mnaser | It’s been quiet here today | |
| 20:42:41 | mnaser | And it’s getting late so I might have to settle for an EU core tomorrow :p | |
| 20:45:47 | melwitt | I can take a look. things have been a bit chaotic today | |
| 20:48:28 | mriedem | the one day sean-k-mooney isn't working 20 hours | |
| 20:49:16 | mriedem | mnaser: you've deployed this patch now and verified it fixes your upgrade issue? | |
| 20:49:30 | melwitt | do we want sean-k-mooney to test this first? | |
| 20:49:42 | mriedem | i think mnaser is testing it in prod | |
| 20:49:56 | mnaser | I have not tested in the environment to be honest | |
| 20:50:08 | mnaser | I can do that now tho | |
| 20:50:15 | mnaser | Gimme a few | |
| 20:50:28 | dansmith | seems pretty clear from the bug that this is the right thing to do | |
| 20:50:38 | melwitt | ok, asked in case that's why you mentioned sean-k-mooney | |
| 20:50:50 | dansmith | obviously a manual test would be nice | |
| 20:51:06 | dansmith | I dropped a +W on the top meaty one.. I can put an upgradeable +1 on the bottom one | |
| 21:03:25 | mnaser | (taking a bit of time, trying to find VMs that have been launched before which are testing) | |
| 21:14:33 | mnaser | dansmith: mriedem melwitt i've tested this one now locally on a vm that confirmed had no mtu set (virsh dumpxml, /proc/pid/cmdline had no host_mtu), live migrated with patch and migration completed succesfully | |
| 21:18:52 | mriedem | i mentioned sean-k-mooney because he added the mtu stuff for bridge/tap types | |
| 21:19:04 | mriedem | and is familiar with this live migration _update_vif_xml stuff | |
| 21:20:48 | melwitt | ack | |
| 21:23:51 | mriedem | while we're all here and having fun, we need to do a rocky release for several upgrade related issues, but need https://review.openstack.org/#/q/topic:bug/1798188+(status:open+OR+status:merged) as part of that, | |
| 21:23:58 | mriedem | and will also want the fix that mnaser just pushed | |
| 21:24:02 | mriedem | mnaser: are you working backports? | |
| 21:24:18 | efried | mriedem: Allocation ratio fix will need to be part of --^ ? | |
| 21:24:32 | mriedem | efried: i don't think that is critical | |
| 21:24:36 | mriedem | annoying, yes | |
| 21:24:39 | mriedem | but not critical | |
| 21:24:39 | efried | okay | |
| 21:28:12 | melwitt | mriedem: I was debating how to update the reno as mentioned by mnaser on the review | |
| 21:29:18 | melwitt | because once all compute hosts are rocky, should be OK to stop running nova-consoleauth with the workaround BUT you also have to make sure you deploy your console proxies per cell and you will still experience all consoles being reset that the point you stop using the workaround (if not all auths already expired) | |
| 21:29:58 | melwitt | it's kind of complicated so I was feeling stuck on whether the reno is conveying all of that well enough | |
| 21:31:21 | mriedem | well, it says use the workaround while you're doing rolling upgrade, so not all computes are rocky yet, as mohammed pointed out, | |
| 21:31:51 | mriedem | and then there is the "Operators may unset the configuration option when:" section which says once you're upgraded (all hosts are Rocky), and stuff is expired, you can drop the workaround, | |
| 21:32:01 | mriedem | if you need to add "and you're running console proxy per cell" to that list, then just add that | |
| 21:32:38 | melwitt | yeah, ok. thanks. I've felt so mired in it that I was having a hard time thinking about it | |
| 21:32:49 | mriedem | i left comments, | |
| 21:33:17 | mriedem | but i think it's just (1) describing what rolling upgrade means and (2) add the part about console proxy being deployer per cell before unsetting the workaround | |
| 21:34:02 | mriedem | we have checks for the former in the nova-status upgrade check, but not the latter, but i'm not sure if it's possible to check the latter via nova-status is it? | |
| 21:39:46 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Cross-cell resize https://review.openstack.org/603930 | |
| 21:39:46 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add Destination.cross_cell_move field https://review.openstack.org/614035 | |
| 21:39:47 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add InstanceAction/Event create() method https://review.openstack.org/614036 | |
| 21:39:47 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Change HostManager to allow scheduling to other cells https://review.openstack.org/614037 | |
| 21:39:57 | melwitt | mriedem: I don't think so. the only possible way to check is if the nova.conf on the console proxy host has [database]connection configured (implying access to a cell database) | |