Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-08-02
08:29:27 gibi bauzas: yes
08:29:44 bauzas gibi: I wanted to discuss your excellent point on https://review.opendev.org/c/openstack/nova/+/838976/3/nova/virt/libvirt/utils.py#597
08:30:25 bauzas fixing it isn't trivial as it either needs to change the callers or to longer use this method
08:31:03 bauzas but I checked which callers are using this method, and this is only for the reshape method and for the recreating method (when you reboot)
08:33:21 bauzas [sbauza@sbauza nova]$ git grep '\.mdev_uuid2name('
08:33:21 bauzas nova/tests/functional/libvirt/test_reshape.py: utils.mdev_uuid2name(mdev_uuid))
08:33:21 bauzas nova/tests/functional/libvirt/test_vgpu.py: mdev_name = libvirt_utils.mdev_uuid2name(uuid)
08:33:21 bauzas nova/tests/functional/libvirt/test_vgpu.py: mdev_name = libvirt_utils.mdev_uuid2name(mdev)
08:33:21 bauzas nova/tests/functional/libvirt/test_vgpu.py: libvirt_utils.mdev_uuid2name(mdevs[0]))
08:33:22 bauzas nova/tests/functional/regressions/test_bug_1951656.py: mdev_name = libvirt_utils.mdev_uuid2name(uuid)
08:33:23 bauzas nova/virt/libvirt/driver.py: dev_name = libvirt_utils.mdev_uuid2name(mdev_uuid)
08:33:24 bauzas nova/virt/libvirt/driver.py: dev_name = libvirt_utils.mdev_uuid2name(mdev_uuid)
08:35:18 bauzas so FWIW, I think we could provide a follow-up patch for it, instead of trying to modify all of the above in the same change
08:36:33 gibi I'm not sure what you imply. Is this not a bug right now to use non suffixed mdev_name with libvirt 7.7+?
08:40:50 bauzas gibi: we already have a bug for recreate()
08:41:24 bauzas so this won't change
08:41:54 gibi OK, so you say, that we use the wrong mdev_name in two cases 1) reshape, but there we only use it internally to nova so libvirt wont see it 2) in recreate but recreate is broken for other reasons as well
08:42:01 gibi Do I understand it correctly?
08:42:24 bauzas 1) for reshapes, we no longer do them
08:42:39 gibi except FFU
08:42:40 bauzas unless someone wants to reshape from Queens to Rocky
08:42:46 gibi ack
08:43:08 bauzas for 2), you got it
08:44:03 bauzas actually, we could fix https://bugs.launchpad.net/nova/+bug/1900800 once we provide the FUP
08:44:05 gibi so 1) can be an issue if someone FFUs from Queens to Train
08:44:26 bauzas 1) only if they run Train with libvirt 7.7
08:44:36 gibi yepp
08:45:05 gibi I agree this is low probabability
08:45:32 bauzas and I'm not saying we shouldn't modify uuid2name
08:45:41 bauzas just saying this couldn't be in the same change
08:45:51 bauzas but by a FUP
08:45:55 gibi OK, lets have a fup
08:51:31 sean-k-mooney bauzas your on pto for the next two weeks yes? from tomorrow?
08:51:46 bauzas sean-k-mooney: from tonight until Aug 29
08:52:26 sean-k-mooney bauzas: did you start trying to port the mdev lib to work around the other issues we have with libvirt
08:52:38 sean-k-mooney if not that is ok
08:53:14 bauzas sean-k-mooney: you mean about using sysfs instead of libvirt for getting the mdevs ?
08:53:17 bauzas no if so
08:53:24 sean-k-mooney ya
08:53:26 sean-k-mooney ok
08:59:27 opendevreview Sylvain Bauza proposed openstack/nova master: Handle mdev devices in libvirt 7.7+ https://review.opendev.org/c/openstack/nova/+/838976
09:00:02 bauzas gibi: sean-k-mooney: update the mdev rename change without modifying the mdev_uuid2name method as we agreed ^
09:00:17 bauzas will work now on a FUP to fix the recreate method
09:04:26 sean-k-mooney ack
09:21:12 gibi dansmith_: when you are up. I have an ovo question. Is there a way to run code before a remotable method is called on the remote end? Like instance.save() is remoteable but I need to run code during instance.save() on the caller side _before_ the rpc call is made to the remote and to call save() there
09:21:49 gibi dansmith_: context is https://review.opendev.org/c/openstack/nova/+/850746
09:22:39 gibi dansmith_: the instance.mutated_migration_context() is not a remotable obviously, but save() is and I would need state to travell between the mutated_migration_context call and a later save() call
09:35:45 opendevreview Balazs Gibizer proposed openstack/nova master: Reproducer for bug 1982497 https://review.opendev.org/c/openstack/nova/+/850672
09:35:46 opendevreview Balazs Gibizer proposed openstack/nova master: Prevent instance.save() under mutated migration context https://review.opendev.org/c/openstack/nova/+/850746
09:35:46 opendevreview Balazs Gibizer proposed openstack/nova master: Avoid saving instance under mutated migration context https://review.opendev.org/c/openstack/nova/+/851832
09:39:02 gibi dansmith_: or alternatively where to stash data in the instance ovo that travels from local to remote but not persisted
10:10:18 sean-k-mooney gibi: you could decorate the remotable method
10:10:38 gibi the mutated_migration_context does not need to be remotable
10:10:54 gibi hm,
10:11:03 gibi we can create two save() methods
10:11:07 sean-k-mooney right but you were askign could we run somthing ofn the remote before it runs right
10:11:08 gibi one non remoteable and one remoteable
10:11:26 sean-k-mooney im not sure about that
10:11:35 gibi with different names of course
10:11:42 gibi and the the non remoteable can call the remoteable
10:11:57 gibi sean-k-mooney: you are a genius, thanks
10:12:07 sean-k-mooney normally we would do that the other way around
10:12:15 sean-k-mooney what exactuly are you tryign to do by the way
10:12:44 gibi I need to prevent instance.save to persist things if the instance is under mutated migration context
10:12:50 gibi so I need a flag on the instance object
10:12:58 gibi but the mutation happens on the local instance
10:13:03 gibi while save runs on the remote instance
10:13:09 sean-k-mooney you can add filed to the instance object directly
10:13:17 sean-k-mooney they wont be saved or sent over the wire
10:13:27 gibi the second is the problem
10:13:31 sean-k-mooney as in "instnace.my_flag=True"
10:13:33 gibi the save runs on the remote
10:13:54 gibi so I need to send the flag on the wire (or check the flag on the local side during save, hence the question)
10:14:06 sean-k-mooney if you want it to be a noop do you
10:14:14 sean-k-mooney you dont want it to save
10:14:25 gibi context in here https://review.opendev.org/c/openstack/nova/+/851832
10:14:28 sean-k-mooney so add a decorator that checks if its set on teh souce
10:14:35 sean-k-mooney and just dont forward if the flag is set
10:14:37 gibi hm
10:14:46 gibi that also possible
10:14:55 gibi if I decorate before the remoteable decorator
10:15:03 gibi then I can inject thing to the local side
10:15:05 sean-k-mooney yep it need to be the other decorator
10:15:13 sean-k-mooney yes
10:15:20 sean-k-mooney and avoid the rpc entirly
10:15:24 gibi ack, thanks
10:15:30 gibi you answered my question
10:15:41 sean-k-mooney :)
10:16:23 sean-k-mooney i think we already do this on the instance object by the way. we cachce some things in the object in memory via filed that are never sent on the wire
10:20:25 gibi I will go with a normal function instead of a wrapper applied by a decorator, as the actual logic is highly save + migration context specific
10:20:45 gibi I will do save() -> remoted_save() indirection
10:21:14 sean-k-mooney hum the issue witht that is you are moving the remoteable decorator to remote_save
10:21:26 sean-k-mooney isnt that a problem
10:22:28 gibi the decorator would do the same technically as the function returned from the decorator would be different
10:22:38 gibi I believe it will not be a problem, but we will see
10:22:51 sean-k-mooney i think it might cause issue for grenade
10:23:04 sean-k-mooney it woudl technically be an rpc change i think
10:23:31 sean-k-mooney the decorator would not alter the name of the remote rpc endpoint for the function
10:23:58 sean-k-mooney it would still be save not remote_save()
10:24:34 gibi ahh

Earlier   Later