| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-09-16 | |||
| 17:29:03 | sean-k-mooney | well the first fix is just one addtion fucntion all in resize_instance to unplug_vifs | |
| 17:29:27 | melwitt | is that consistent with what we do with volumes today too? | |
| 17:29:34 | sean-k-mooney | bit that makes it trickin is to fully solve the diffent backend case i need to remove the current call in confirm | |
| 17:29:56 | sean-k-mooney | melwitt: ya for volumes we remove attacments in resize_instance | |
| 17:30:32 | melwitt | ok. it seems like it would make sense to have them be consistent but I don't know the reason vifs are handled differently | |
| 17:30:55 | sean-k-mooney | well technically in migrate_disk_and_poweroff | |
| 17:30:56 | sean-k-mooney | https://github.com/openstack/nova/blob/e0f088c95d05e9cf32d4af4c7cfc20566b17f8e1/nova/virt/libvirt/driver.py#L10362 | |
| 17:31:22 | sean-k-mooney | and im suggesting adding self.unplug_vifs here https://github.com/openstack/nova/blob/e0f088c95d05e9cf32d4af4c7cfc20566b17f8e1/nova/virt/libvirt/driver.py#L10357 | |
| 17:31:22 | melwitt | yeah, I did see the volume detach there | |
| 17:31:38 | sean-k-mooney | basicly 5 lines up | |
| 17:32:30 | melwitt | yeah, seems to make sense to me | |
| 17:32:48 | sean-k-mooney | melwitt: basically power_off call _destory() not destroy() to delete the domain xml without remving the disk images | |
| 17:32:57 | sean-k-mooney | so we can revert without copying data | |
| 17:33:08 | sean-k-mooney | but _destory() does not call unplug_vifs | |
| 17:33:25 | sean-k-mooney | destroy() does via the call to cleanup() | |
| 17:33:30 | sean-k-mooney | which delete the disk too | |
| 17:33:43 | melwitt | right | |
| 17:34:22 | sean-k-mooney | and today conrim does an rpc from the dest to the source to call unplug_vifs | |
| 17:34:50 | sean-k-mooney | here in cleanup_resize https://github.com/openstack/nova/blob/e0f088c95d05e9cf32d4af4c7cfc20566b17f8e1/nova/virt/libvirt/driver.py#L1665 | |
| 17:35:43 | melwitt | yeah I guess I wonder what are the potential issues if the deployment is in the middle of an upgrade | |
| 17:35:50 | sean-k-mooney | for revert we call plug_vifs in create_instace_with_networks here https://github.com/openstack/nova/blob/e0f088c95d05e9cf32d4af4c7cfc20566b17f8e1/nova/virt/libvirt/driver.py#L6704 https://github.com/openstack/nova/blob/e0f088c95d05e9cf32d4af4c7cfc20566b17f8e1/nova/virt/libvirt/driver.py#L10681-L10683 | |
| 17:36:09 | openstackgerrit | Lee Yarwood proposed openstack/nova-specs master: WIP/DNM - Flavor and image defined ephemeral storage encryption https://review.opendev.org/752284 | |
| 17:36:15 | sean-k-mooney | melwitt: right so if i dont remove the unplug_vifs form the cleanup in confim | |
| 17:36:19 | sean-k-mooney | i think its ok if i do | |
| 17:36:26 | lyarwood | sean-k-mooney: sorry just pushing something and I need to drop again, can we catch up about that backport stuff in the morning? | |
| 17:36:42 | lyarwood | s/morning/your\ morning/g ;) | |
| 17:36:47 | sean-k-mooney | then if i have an old souce and a new dest then i think we dont clean up the vifs | |
| 17:37:00 | sean-k-mooney | lyarwood: ya we can no rush | |
| 17:37:19 | sean-k-mooney | melwitt: im not sure how to handel that other then leave the extra call to unplug_vifs in the backport | |
| 17:37:47 | sean-k-mooney | melwitt: unplug_vifs shoudl be callable twice without any ill effects | |
| 17:38:36 | melwitt | yeah, well wouldn't you have to leave it on master (not only backports) for one cycle? to bridge the N-1 to N upgrade? | |
| 17:39:10 | sean-k-mooney | melwitt: well the proablem is i need to backport the cve issue to like queens eventually | |
| 17:39:43 | sean-k-mooney | what i think i would have to do is keep the call to unplug_vifs in cleanup but wrap it in a try excetp | |
| 17:39:59 | melwitt | I'm just saying re: leaving the extra call, I think you'd have to leave it on master too, not only leave it on the backports. because the upgrade issue exists for master as well | |
| 17:40:08 | sean-k-mooney | oh right | |
| 17:40:17 | sean-k-mooney | i woudl have to leave it on master for a cycle ya | |
| 17:40:46 | sean-k-mooney | ill put the patches up for peopel to see as 3 patches | |
| 17:41:10 | sean-k-mooney | 1 for the new call in resize. one for the cve fix which is alredy up for review and one for the extra call removal | |
| 17:41:28 | sean-k-mooney | and we can defer that last one for a cycle | |
| 17:42:04 | sean-k-mooney | and i guess we can see if peopel think of any other reason not to do it this way. | |
| 17:42:10 | melwitt | yeah, so AFAICT the backport concern here would be the complexity and impact to something that is supposed to be "stable" but it's needed for a CVE so I think that makes it backportable (again unless I'm missing something) | |
| 17:43:03 | sean-k-mooney | ya if we think its backportable and we are happy with it on master i guess i dont have to rush the backport either | |
| 17:43:17 | sean-k-mooney | e.g. we coudl wait a while and let it back | |
| 17:43:20 | sean-k-mooney | *bake | |
| 17:44:24 | melwitt | yeah I'm just concerned about there being a bug or edge case that crops up in the gate and then we have a fix to backport 5 times too | |
| 17:44:51 | melwitt | not the end of the world, we did it recently :P but the goal is to avoid that | |
| 17:45:10 | sean-k-mooney | :) ya im ok with that | |
| 17:45:26 | sean-k-mooney | this partcalar issue has been dragin on since 2018 or longer | |
| 17:45:27 | melwitt | let's see what other ppl think. I worry I'm missing something unbackportable about it | |
| 17:45:46 | sean-k-mooney | 2017-11-24 | |
| 17:46:03 | melwitt | yeah, I think that might be the same neutron security bug I emailed about downstream a long time ago | |
| 17:46:22 | sean-k-mooney | i started working on this when i was still at intel | |
| 17:46:31 | sean-k-mooney | we have fixed in in a number of edgecases | |
| 17:46:41 | sean-k-mooney | but there is still 1 that is unfixed | |
| 17:46:51 | sean-k-mooney | just trying to get the fine case closed | |
| 17:47:23 | melwitt | understood | |
| 17:47:52 | sean-k-mooney | https://review.opendev.org/#/c/602432/ fixes the final case but its failing or reverts because of the change in unplug behaivor wehn we get rid of the libvirt race | |
| 17:59:03 | sean-k-mooney | melwitt: oh one related question do we think this could be an RC1 candiate so that we could count victoria as the first release or would wallaby have to be the first release with X for the removal of the second call | |
| 17:59:18 | sean-k-mooney | i guess we can cross that bridge wehn we come to it | |
| 17:59:52 | sean-k-mooney | but im not really sure given how latent both issue are that it qualifies for RC1 | |
| 18:00:18 | sean-k-mooney | i would like it to but i would like many things to be true that are not :) | |
| 18:00:38 | melwitt | sean-k-mooney: yeah I think it'd be a hard sell for RC1 because of how latent | |
| 18:01:13 | sean-k-mooney | ya ok. when i leave the todo commont for remoinv it ill say after wallaby | |
| 18:01:35 | melwitt | but you could bring it up at the nova meeting tomorrow to get more input | |
| 18:02:28 | sean-k-mooney | ya. i asked the peroson that reported the other bug if they were ok with me updating there patch to just do the method move if so i should have a patch up before then if not ill submit a sperate patch for that i guess | |
| 18:02:51 | sean-k-mooney | in either case i can add it to the open disucssion secation at the end | |
| 18:03:06 | melwitt | but eh... looking at the release schedule RC1 is Sep 24, not sure we could get proper review done by then | |
| 18:03:26 | sean-k-mooney | ya its rather tight | |
| 18:03:40 | sean-k-mooney | ill just assume this will have to be backported to stable/victoria | |
| 18:03:50 | sean-k-mooney | its fine | |
| 18:04:02 | melwitt | yeah, realistically I think that will be the case | |
| 18:04:36 | sean-k-mooney | ya no worries. | |
| 18:05:17 | sean-k-mooney | ill leave it of the agenda so and just ask lee and other for review once the patches are ready | |
| 18:05:58 | sean-k-mooney | i havent looked at the rc-potential bugs list yet | |
| 18:06:05 | sean-k-mooney | do we have any/many | |
| 18:07:20 | sean-k-mooney | oh just one https://bugs.launchpad.net/nova/+bugs?field.tag=victoria-rc-potential | |
| 18:07:28 | openstack | Launchpad bug 1882521 in OpenStack Compute (nova) "Failing device detachments on Focal" [High,Confirmed] - Assigned to Lee Yarwood (lyarwood) | |
| 18:07:28 | sean-k-mooney | https://bugs.launchpad.net/nova/+bug/1882521 | |
| 18:08:08 | openstack | Launchpad bug 1894804 in QEMU "Second DEVICE_DELETED event missing during virtio-blk disk device detach" [Undecided,New] | |
| 18:08:08 | sean-k-mooney | and lee has raised a qemu bug for that https://bugs.launchpad.net/qemu/+bug/1894804 | |
| 18:08:27 | sean-k-mooney | so i guess that is not really an rc blocker | |
| 18:10:36 | openstack | Launchpad bug 1894804 in QEMU "Second DEVICE_DELETED event missing during virtio-blk disk device detach" [Undecided,New] | |
| 18:10:36 | sean-k-mooney | and danpb basically conrimed it as a qemu bug in https://bugs.launchpad.net/qemu/+bug/1894804/comments/3 | |
| 18:10:43 | melwitt | yeah AFAICT there isn't anything we can do to workaround that either | |
| 18:11:36 | sean-k-mooney | we might be able to mitigate it by using virtio-scsi instead of virtio-block | |
| 18:11:45 | sean-k-mooney | but ya not really | |
| 18:11:57 | sean-k-mooney | other then skip it in tempest for now | |
| 19:07:23 | openstack | bug 1894966 in OpenStack Compute (nova) "Create servergroup failed with unexpected error" [Low,In progress] https://launchpad.net/bugs/1894966 - Assigned to Stephen Finucane (stephenfinucane) | |
| 19:07:23 | openstackgerrit | Merged openstack/nova master: tests: Add regression test for bug 1894966 https://review.opendev.org/752210 | |
| 19:20:09 | openstackgerrit | Merged openstack/os-vif master: Update master for stable/victoria https://review.opendev.org/750926 | |
| 19:33:37 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Skip cinder_encryption_key_id check when booting from volume https://review.opendev.org/752090 | |
| 19:33:37 | openstack | bug 1895696 in OpenStack Compute (nova) "unable to boot instance from encrypted volume created from a glance image of an encrypted volume" [Medium,In progress] https://launchpad.net/bugs/1895696 - Assigned to Lee Yarwood (lyarwood) | |
| 19:33:37 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Add regression test for bug #1895696 https://review.opendev.org/752247 | |
| 19:44:27 | openstackgerrit | Merged openstack/python-novaclient master: Remove install unnecessary packages https://review.opendev.org/751637 | |
| 20:39:45 | openstackgerrit | Merged openstack/os-vif master: Add Python3 wallaby unit tests https://review.opendev.org/750927 | |
| 21:49:22 | openstackgerrit | Merged openstack/nova master: Fix error that cannot overwrite policy rule for 'forced_host' https://review.opendev.org/751152 | |
| 22:43:08 | openstackgerrit | Merged openstack/nova stable/rocky: Removed the host FQDN from the exception message https://review.opendev.org/749612 | |
| 23:50:50 | brinzhang0 | gibi, gmann, stephenfin: change 500-->400 is ok for me too ^^ thanks | |
| #openstack-nova - 2020-09-17 | |||
| 05:44:37 | openstack | bug 1894966 in OpenStack Compute (nova) "Create servergroup failed with unexpected error" [Low,In progress] https://launchpad.net/bugs/1894966 - Assigned to Stephen Finucane (stephenfinucane) | |
| 05:44:37 | openstackgerrit | Brin Zhang proposed openstack/nova stable/ussuri: tests: Add regression test for bug 1894966 https://review.opendev.org/752371 | |