Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-04-03
07:41:51 auniyal Hi sean-k-mooney
07:42:15 auniyal https://review.opendev.org/c/openstack/nova/+/877500 - (Don't provide MTU value in metadata service if DHCP is enabled
07:42:15 auniyal )
07:42:36 auniyal is this required in yoga as well ?
07:47:15 bauzas auniyal: if you read the bug report, you'll understand that it's not related to some Nova release, right ?
07:47:46 bauzas it's due to the fact that we pass a wrong MTU to the metadata API, so cloud-init sets it
07:48:05 bauzas since the operator provided another MTU value for the DHCP domain, we need to use it
09:41:41 gibi bauzas: I caught up on the Friday ptg etherpad. Sorry for missing the discussion in real time.
09:41:51 bauzas np at all
09:42:00 bauzas hope your wife was ok
09:42:10 bauzas anyway, /me needs to go off
09:42:18 gibi bauzas: I agree to try to discuss the limited scope lower constriants job during one of the weekly meetings
09:42:22 bauzas (yet again taxi needs)
12:05:29 dvo-plv sean-k-mooney: Hello. I have a question regarding third patry cicd from napatech
12:05:50 sean-k-mooney sure
12:06:46 dvo-plv Could we create our own napatech tempest plugin, maybe just a copy of renegade job or rebase some otehr tests, what will be required, but with a modification for our configuration stesps, create vm with virtio-forwarder or set device_spec varainle, etc?
12:07:11 sean-k-mooney you could but that shoudl not be required
12:07:26 sean-k-mooney tempest allows you to set teh vnic type to use
12:08:03 sean-k-mooney https://github.com/openstack/tempest/blob/master/tempest/config.py#L814-L821
12:08:25 sean-k-mooney so if you set that to virtio-forwarder then it will use that when creating ports
12:09:59 sean-k-mooney dvo-plv: https://docs.openstack.org/neutron/latest/contributor/policies/thirdparty-ci.htmlhttps://docs.openstack.org/neutron/latest/contributor/policies/thirdparty-ci.html is neutrons requimentss for third party ci
12:10:01 dvo-plv I see, Could you also clarify what tests we have to execute for verification? smoke and renegade ?
12:10:21 sean-k-mooney im not sure what renegade is but smoke is not enough
12:10:32 opendevreview Merged openstack/nova stable/train: [compute] always set instance.host in post_livemigration https://review.opendev.org/c/openstack/nova/+/864055
12:10:47 sean-k-mooney ideally you woudl run the networkign and compute api tests and network basic ops as a minium
12:11:55 dvo-plv I see, thanks
12:13:01 dvo-plv Do you have some time for our blueprint with packed ring https://review.opendev.org/c/openstack/nova-specs/+/868377 ?
12:15:03 damnthem hello. i'm having trouble figuring out why does during openstack server backup nova creates two copies of instance disk in temp folder (one, which is mirror name.delta, and second one, which is a "flat copy" of that mirror) https://opendev.org/openstack/nova/src/commit/29de62bf3b3bf5eda8986bc94babf1c94d67bd4e/nova/virt/libvirt/driver.py#L3310-L3365 There are comments in code that suggests that delta is part of backing chain b
12:16:03 sean-k-mooney dvo-plv: ill try and find some time to do upstream view in general tomorrow morning. im not sure ill have time to do reviews today but ill try and do a review of openspecs tomorrow
12:17:22 sean-k-mooney damnthem: locally the vm will execute form the delta disk but we need to upload the flat image to glance
12:17:42 sean-k-mooney glance images cannot be delta disk over other images
12:18:41 sean-k-mooney at least not for qcow/raw images
12:19:11 dvo-plv Thank you, have a good day
12:19:27 sean-k-mooney if its boot from volume or nova is using rbd then we do the snapshot directly in the storage backend and do a thin snapshot
12:19:38 sean-k-mooney if the storage backend supports that
12:37:41 opendevreview liang jiechao proposed openstack/nova-specs master: Generic vdpa spec https://review.opendev.org/c/openstack/nova-specs/+/879338
12:47:52 damnthem sean-k-mooney: vm works locally from {instance}/disk isn't it? Also domxml and qemu-img info doesnt show any backing chains for mirror/delta. And dev.rebase creates full copy of image (mirror https://qemu-project.gitlab.io/qemu/interop/live-block-operations.html#live-disk-synchronization-drive-mirror-and-blockdev-mirror) https://opendev.org/openstack/nova/src/commit/29de62bf3b3bf5eda8986bc94babf1c94d67bd4e/nova/virt/libvirt/d
12:48:53 opendevreview liang jiechao proposed openstack/nova-specs master: Generic vdpa spec https://review.opendev.org/c/openstack/nova-specs/+/879338
12:50:46 sean-k-mooney damnthem: the specific way we create snapshots is rather complicated and is done in a specic way for both legacy and technical reasons related to minimising the impact on the running guest
12:51:56 Uggla gibi, Hi I'm looking at https://review.opendev.org/c/openstack/nova/+/855664/ , so it needs to be backported down to train ?
12:53:59 sean-k-mooney damnthem: https://github.com/openstack/nova/blob/29de62bf3b3bf5eda8986bc94babf1c94d67bd4e/nova/virt/libvirt/driver.py#L3286-L3369 this is the relevent code
12:57:34 sean-k-mooney damnthem: https://github.com/openstack/nova/commit/46de2d1e2d0abd6fdcd4da13facaf3225c721f5e was the orgianl patch that add live-snapshots and it descibe the limitation around blockrebase and shallow copies
12:59:24 sean-k-mooney we later optimised this futher in https://github.com/openstack/nova/commit/caf5faf55670ab212868498e421bedc074fafd89 to reduce the time we need to freeze the fs
13:02:25 damnthem sean-k-mooney: Yeah i read that, and that's actually source of my confusion. Commit message says: "This process ultimately produces a CoW file, representing only the current delta between the root disk and backing file". But it's not in current state. There are 3 full copy at some point: instance disk, mirror and converted image from mirror.
13:08:48 sean-k-mooney i need to prepare for a meeting shortly so perhaps others can continue this converstation. without digining into the code my understanding of the process a a high level is we do somthign like this
13:09:26 sean-k-mooney first we create a delat disk by using the same backing as the vm image
13:10:01 sean-k-mooney this basically recreates teh state to the vm before it started runing for the first tiem
13:11:21 sean-k-mooney we then do a blockdevie rebase on the delta disk to update it with the changes that have hppened since the vm booted.
13:12:04 sean-k-mooney we then freeze the guest filesystem and abort the rebase job
13:12:09 sean-k-mooney instead of commiting it
13:12:20 sean-k-mooney then unfreeze the filesystem
13:12:44 sean-k-mooney at this point the vm is back to runing form the orginal instance disk
13:13:09 sean-k-mooney and we have a copy of the filesytem changes in the delta disk
13:14:19 sean-k-mooney we then update the ownwershp of the delta disk so that its owned by nova and revert the guest xml back ot what it was before the snapshot
13:14:45 sean-k-mooney then we flaten the delta disk into the final format for uploading
13:14:53 sean-k-mooney and delete the delta disk
13:15:02 sean-k-mooney finally we upload the image to glance.
13:15:56 sean-k-mooney by creating the delta disk as an overlay of the backing file durint the snapshot we only need enough storage for the changes since the guest booted
13:16:22 damnthem sean-k-mooney: thank you. I think i understood where is difference in my case and why it's works irrational for me.
13:16:24 sean-k-mooney while we are doing the format convertion we need storage for the vm + deta disk + flattened image
13:17:03 sean-k-mooney and after the snap shot we are just back to the orginal disk
13:33:55 damnthem sean-k-mooney: to be short - we disabled used_cow_images, so backing stores disabled .So this whole image/snapshot juggling looks pointless from outside. Thank you for helping me figure this out
13:40:22 sean-k-mooney damnthem: so your using raw images
13:40:45 sean-k-mooney this is still useful in this case for older release as it reduces the time the mirror action takes
14:39:45 opendevreview Alexey Stupnikov proposed openstack/nova master: Process unlimited exceptions raised by unplug_vifs https://review.opendev.org/c/openstack/nova/+/879350
14:41:48 auniyal Hi dansmith
14:41:55 dansmith hi
14:41:56 auniyal regarding this: https://review.opendev.org/c/openstack/nova-specs/+/878757
14:42:02 auniyal thanks for looking :)
14:42:11 auniyal as you said, now I too think the best way to update DB is with process of restarting instnace.
14:42:21 auniyal I was looking for the place where, we can updated DB, on instance shutoff.
14:42:33 auniyal I think it should be in compute/api as it has stop and start functionality.
14:42:50 auniyal I was also looking for list of operation nova might perform on instance shutdown or start, but could not find one.
14:43:02 auniyal Is this alright to add a decorator which perform all operations on instnace shutoff
14:43:15 auniyal something like
14:43:20 auniyal @post_shutoff_actions
14:43:20 auniyal def stop(instance):
14:43:20 auniyal pass
14:44:47 dansmith auniyal: compute/api is run on the caller, which means the api service would run that code for stop(), so no, I don't think that's best place
14:44:50 dansmith should be in manager
14:46:01 auniyal at this https://opendev.org/openstack/nova/src/branch/master/nova/compute/manager.py#L3317
15:02:58 dansmith auniyal: perhaps, but it probably would be better on start, but more like the lower level spawn so that it catches reboot, start, etc
15:05:05 auniyal dansmith, ack,
15:06:07 auniyal I didn't get, why we should not run DB update at caller (i.e controller as nova-api serice I believe !!)
15:06:25 auniyal is it because this action is DB related
15:08:15 dansmith no, for several reasons:
15:08:46 dansmith It needs to call to cinder and the database so it may be slow/blocking and holding the API caller while you do that is not good
15:09:09 dansmith it also means that it would only work for an actual api stop call and not for other things like reboot, or crash recovery, or guest-initiated reboot, etc
15:11:17 auniyal ack, got it,
15:37:30 opendevreview Alexey Stupnikov proposed openstack/nova master: Process unlimited exceptions raised by unplug_vifs https://review.opendev.org/c/openstack/nova/+/879350
15:46:58 gibi Uggla: I we we need https://review.opendev.org/c/openstack/nova/+/855664/ in train yes
15:47:18 gibi Uggla: is there a complication with the backport?
15:47:42 Uggla gibi, all ports should be upstream ? Any downstream to do ?
15:49:11 Uggla gibi, no I just try to check the "scope".
15:57:39 gibi Uggla: as we have train open upstream still we expected to land the fix upstream.
15:58:15 gibi if there is high pressure to get the fix earlier downstream then you can propose the downstream backport before the upstream backport lands, but we still need the upstream backport too
15:58:34 gibi (we probably discuss this downstream :D)
15:59:14 Uggla ok sounds good.
15:59:54 gibi Uggla: thanks for picking that fix up
16:00:32 Uggla gibi, you are welcome.

Earlier   Later