Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-03-31
17:13:28 melwitt elodilles: yeah honestly I usually drink what's good in the area. when I spent time in france and italy for example, I switched largely to wine while I was there bc there was much more good wine than good beer around :)
17:15:17 elodilles yepp, "when in Rome..." ;)
17:15:21 melwitt the beer choices were basically peroni or peroni
17:19:26 elodilles in restaurants, i guess the situation is similar here (having 1 or 2 kinds of beer only) except in the capital or bigger cities
17:19:57 elodilles (and of course where there are some breweries)
17:22:16 elodilles but i can imagine places which are famous for their wines don't need big selection of beer, of course :D
17:23:06 melwitt yeah exactly. even if they had them they probably wouldn't sell much. so I get it
17:24:42 elodilles :]
17:25:57 dansmith bauzas: so, did I miss anything important from the rest of the nova stuff after I dropped?
17:27:53 bauzas dansmith: nope, not really
17:28:08 dansmith cool
17:28:11 bauzas most topics were merely whether those were bugs or features
17:28:15 bauzas but,
17:28:26 bauzas we had one topic about a nova-manage command spec
17:28:33 bauzas you may be interested in the spec reading
17:28:51 bauzas I had concerns about the residues it could leave on the compute
17:30:03 dansmith okay
23:01:56 opendevreview melanie witt proposed openstack/nova master: Support rescue with ephemeral encryption https://review.opendev.org/c/openstack/nova/+/873675
23:01:57 opendevreview melanie witt proposed openstack/nova master: Add reset_encryption_fields() and save_all() to BlockDeviceMappingList https://review.opendev.org/c/openstack/nova/+/870938
23:01:57 opendevreview melanie witt proposed openstack/nova master: Update driver BDMs with ephemeral encryption image properties https://review.opendev.org/c/openstack/nova/+/870939
23:01:58 opendevreview melanie witt proposed openstack/nova master: libvirt: Introduce support for qcow2 with LUKS https://review.opendev.org/c/openstack/nova/+/772273
23:08:00 opendevreview melanie witt proposed openstack/nova master: DNM test ephemeral encryption + resize: qcow2, raw https://review.opendev.org/c/openstack/nova/+/862416
#openstack-nova - 2023-04-01
20:51:34 opendevreview sean mooney proposed openstack/nova master: [DNM] build apline image in nova-next https://review.opendev.org/c/openstack/nova/+/879220
#openstack-nova - 2023-04-03
06:20:48 opendevreview Amit Uniyal proposed openstack/nova-specs master: Add cleanup flag to remove dangling volumes https://review.opendev.org/c/openstack/nova-specs/+/878757
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

Earlier   Later