Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-06-23
14:40:41 sean-k-mooney weird
14:40:49 sean-k-mooney both thos test refernce the same volume 7688b3f1-6549-4e0c-a507-9789ddc2eb95
14:41:08 gibi elodilles: I've just stopped thinking about the above vGPU problem
14:41:30 sean-k-mooney that should not happen right
14:41:41 sean-k-mooney two tests refering to the same volume uuid 7688b3f1-6549-4e0c-a507-9789ddc2eb95
14:41:51 sean-k-mooney if they run in parally they would conflict
14:42:00 gibi sean-k-mooney: wich two test cases?
14:42:05 gibi sean-k-mooney: I see a testcase and a tear down
14:42:11 gibi of the suite
14:42:19 sean-k-mooney oh ya its the tear down method
14:42:29 sean-k-mooney ok that make a liit more sense
14:42:29 elodilles gibi: well I've seen that there was an ongoing discussion so I did not want to interrupt earlier :)
14:43:42 sean-k-mooney ok so the teardown failed becasue presumable the volume was still attached to the vm
14:43:54 sean-k-mooney it was in state detaching
14:46:28 gibi it is trying to detach in a loop so I guess it is the original detach problem
14:46:39 gibi for what we created the notification based solution
14:46:47 gibi but that solution is not in victoria
14:46:58 sean-k-mooney ya the detach starts at Jun 21 09:20:16.007823
14:48:00 gibi so either we increase the timeout value before we retry in victoria or backport the notification based solution to victoria
14:48:39 sean-k-mooney we are calling os_brick.initiator.connectors.iscsi.ISCSIConnector.disconnect_volume on it
14:48:59 sean-k-mooney we would not do that if the detach ahs not commpeted right?
14:49:37 gibi sean-k-mooney: I don't know. what I know that the detach is not completed from libvirt perspective, it still reports the device in the live domain after 7 retries
14:50:03 sean-k-mooney this is happening as part of a live migration
14:51:08 sean-k-mooney this looks odd what is the test actully doing
14:51:38 sean-k-mooney it look like we are runign post live migration on the souce which is tearing odwn the volume while its potentioanly still detaching
14:51:58 gibi I think lyarwood has more context on this detach problem
14:52:13 sean-k-mooney im wonderign if the tempest test is broken
14:52:42 sean-k-mooney e.g. is it issuing a detach and then a live migrate without waiting for the detach to complete
14:53:45 sean-k-mooney this is the test https://github.com/openstack/tempest/blob/master/tempest/api/compute/admin/test_live_migration.py#L178-L204
14:54:30 sean-k-mooney thats doing an attach
14:54:41 sean-k-mooney but its not doing a detach
14:54:53 sean-k-mooney its also not waiting to ensure its actully attached
14:55:06 sean-k-mooney unless self.attach_volume is doint that internally
14:56:31 sean-k-mooney ok if the attach fails its cleanup funciton does a detach im assuming https://github.com/openstack/tempest/blob/53c02181f87804a4ba8ddf6288ea1f7717234c2a/tempest/api/compute/base.py#L554-L591
14:56:47 sean-k-mooney it is waiting internally
14:57:42 sean-k-mooney https://github.com/openstack/tempest/blob/53c02181f87804a4ba8ddf6288ea1f7717234c2a/tempest/api/compute/base.py#L590
14:58:02 sean-k-mooney can we see the volume attach complete in the logs
15:00:39 sean-k-mooney we do the attachment in libvirt at un 21 09:20:00.476733
15:10:10 lyarwood if we are still talking about https://c5d6a707d1df71acd55f-fbeed0693cac4a6e5441d43111515edc.ssl.cf5.rackcdn.com/787252/4/gate/nova-live-migration/706ec17/testr_results.html it's just another basic detach failure from the live domain
15:10:22 lyarwood after the test has passed and we are cleaning up
15:12:12 lyarwood I really need to land https://review.opendev.org/c/openstack/tempest/+/794757 so we can get some guestOS logs in this case
15:13:30 gibi lyarwood: that run is from stable/victoria so we don't have the new detach code there. Do you think it would help if we try to backport the new detach code? or is it possibly unrelated?
15:13:31 lyarwood or we could just Depends-On that from a DNM stable/victoria change
15:13:38 elodilles lyarwood: so you are saying that this is similar like bug #1931716 but not the exact same case?
15:14:04 lyarwood gibi: we've seen failures of this test on master so this time I don't think backporting that code is going to help
15:14:06 lyarwood brb
15:15:15 gibi lyarwood: OK, then I agree to land the tempest improvement first to get more info
15:18:44 opendevreview Elod Illes proposed openstack/nova stable/victoria: DNM: volume detach test https://review.opendev.org/c/openstack/nova/+/797675
15:19:30 elodilles I've created the DNM patch what lyarwood suggested ^^^
15:21:51 lyarwood elodilles: thanks
15:22:23 elodilles np. let's see what happens :)
15:30:06 lyarwood elodilles: I have a change to skip the test on master btw that we could also backport if we see the same soft lockups
15:30:42 opendevreview Stephen Finucane proposed openstack/nova stable/victoria: Test numa and vcpu topologies bug: #1910466 https://review.opendev.org/c/openstack/nova/+/797680
15:30:43 opendevreview Stephen Finucane proposed openstack/nova stable/victoria: Fix max cpu topologies with numa affinity https://review.opendev.org/c/openstack/nova/+/797681
15:35:54 elodilles lyarwood: thanks, good to know that, we might need to backport that then if needed
15:46:02 kashyap gibi: lyarwood: sean-k-mooney: When you get a min, have a look to see if you spot any holes there: https://blueprints.launchpad.net/nova/+spec/virtio-as-default-display-device
15:50:50 sean-k-mooney that will need a spec most likely
15:51:11 sean-k-mooney im not agaisnt it but we need to record the current modele in use
15:51:17 sean-k-mooney and then only change the default for new instnaces
15:59:48 sean-k-mooney lyarwood: so in this case we dont actully want to do the detach on succesful migration right
16:00:01 sean-k-mooney that is jsut an artifcat of the way the cleanup is done
16:00:11 sean-k-mooney we just want to delete the vm then delete the volume
16:00:19 lyarwood sean-k-mooney: yeah it's just part of the tempest cleanup code that's added when we initially attach
16:00:33 sean-k-mooney could we modify that
16:00:45 lyarwood indeed, we don't need to detach as part of this test
16:00:52 sean-k-mooney add a flag to attach e.g cleanup=false
16:00:55 lyarwood so we could just nuke the instance and move on with our lives
16:01:18 sean-k-mooney yep
16:01:21 lyarwood yup, the only issue is that there's duplication in the tempest code base with lots of this utility code
16:01:32 lyarwood but I can do this for the compute attach volume part at least
16:01:42 lyarwood I think there's another helper in the volume api tests
16:01:47 lyarwood and maybe the scenario manager
16:02:21 sean-k-mooney it should in thoery decrease test execution time
16:03:12 lyarwood Yup we would however drop some coverage of detaching volumes
16:34:00 sean-k-mooney lyarwood: we would but in principal we have tests for that specifically
16:34:23 sean-k-mooney detach is not really a part of what we are testing in this case
16:34:37 sean-k-mooney it does expose racecondition more as we see here
16:34:49 sean-k-mooney but im not sure that is always a good thing
17:19:37 opendevreview Lee Yarwood proposed openstack/nova master: WIP compute: Avoid calling detach with src connection_info during LM rollback https://review.opendev.org/c/openstack/nova/+/797725
17:27:29 sean-k-mooney that was quick
17:39:33 ganso lyarwood: hi! is there anything pending on https://review.opendev.org/c/openstack/nova/+/795432 so it can be merged? That patch was the latest one to pass CI. There are several patches (including one with +W) that haven't had a single positive CI run
19:37:58 lyarwood elodilles: https://review.opendev.org/c/openstack/nova/+/795432 - can you hit this in the morning? I've upgraded my +1 to +2 to move it along.
19:38:17 lyarwood ganso: apologies, I'll work with elodilles and the other stable cores to unblock things in the morning
19:39:47 ganso lyarwood: np! thank you very much! I was mostly wondering if something else was pending because I had rebased on top of it and it still failed. See latest comments in https://review.opendev.org/c/openstack/nova/+/796719
#openstack-nova - 2021-06-24
07:25:05 opendevreview Slawek Kaplonski proposed openstack/nova stable/ussuri: [neutron] Get only ID and name of the SGs from Neutron https://review.opendev.org/c/openstack/nova/+/787253
07:47:10 opendevreview Elod Illes proposed openstack/nova stable/ussuri: zuul: Replace grenade and nova-grenade-multinode with grenade-multinode https://review.opendev.org/c/openstack/nova/+/794675
07:51:55 elodilles lyarwood: uhh, I almost messed up the supermegasquash :S
07:52:19 elodilles lyarwood: btw, do we really need there the "Replace nova-live-migration with zuulv3 jobs" ?
07:52:26 elodilles :/
08:18:32 elodilles lyarwood: anyway, I've +2+W'd the supermegasquash
08:23:16 elodilles lyarwood: I also abandoned the ussuri patches that were squashed into the supermegasquash
08:23:40 elodilles just to clean up a bit
08:40:05 lyarwood ganso: ah apologies I see now, the nova-next failure in your stable/ussuri change looks like a known issue with the bionic version of QEMU
08:40:59 lyarwood ganso: we used the zuulv3 change to the live migration jobs to fix this in later releases by moving to Focal but that isn't an option on Ussuri, Train etc.
08:41:20 lyarwood ganso: so tl;dr the zuulv3 changes might not resolve this issue
08:41:42 lyarwood ganso: however we could skip the test if it's failing constantly across the remaining Bionic based branches
08:42:35 lyarwood elodilles: as above I'm not sure that we do need that back on stable/ussuri but at the same time it shouldn't hurt
08:43:18 lyarwood elodilles: the label is defined in the parent tempest job and everything in our job definition should be generic (with the edits I made to the evacuation test role) to run on Bionic
08:46:34 elodilles lyarwood: ok, thanks, meanwhile I came to the same conclusion that it probably doesn't hurt but on the other hand fixes the gate, so i +w'd the patch :)
08:47:04 lyarwood that's the thing, I've not seen an example where it clearly does just yet but hopefully I've missed something

Earlier   Later