| opendevreview | Amit Uniyal proposed openstack/nova-specs master: Add cleanup flag to remove dangling volumes https://review.opendev.org/c/openstack/nova-specs/+/878757 | 06:20 |
|---|---|---|
| *** dasm is now known as Guest9758 | 06:52 | |
| auniyal | Hi sean-k-mooney | 07:41 |
| auniyal | https://review.opendev.org/c/openstack/nova/+/877500 - (Don't provide MTU value in metadata service if DHCP is enabled | 07:42 |
| auniyal | ) | 07:42 |
| auniyal | is this required in yoga as well ? | 07:42 |
| bauzas | auniyal: if you read the bug report, you'll understand that it's not related to some Nova release, right ? | 07:47 |
| bauzas | it's due to the fact that we pass a wrong MTU to the metadata API, so cloud-init sets it | 07:47 |
| bauzas | since the operator provided another MTU value for the DHCP domain, we need to use it | 07:48 |
| * bauzas needs his 3rd coffee now, I'm not really good at writing | 08:44 | |
| gibi | bauzas: I caught up on the Friday ptg etherpad. Sorry for missing the discussion in real time. | 09:41 |
| bauzas | np at all | 09:41 |
| bauzas | hope your wife was ok | 09:42 |
| bauzas | anyway, /me needs to go off | 09:42 |
| gibi | bauzas: I agree to try to discuss the limited scope lower constriants job during one of the weekly meetings | 09:42 |
| bauzas | (yet again taxi needs) | 09:42 |
| * bauzas will add the ptg summary this afternoon (hopefully) | 09:42 | |
| dvo-plv | sean-k-mooney: Hello. I have a question regarding third patry cicd from napatech | 12:05 |
| sean-k-mooney | sure | 12:05 |
| 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:06 |
| sean-k-mooney | you could but that shoudl not be required | 12:07 |
| sean-k-mooney | tempest allows you to set teh vnic type to use | 12:07 |
| sean-k-mooney | https://github.com/openstack/tempest/blob/master/tempest/config.py#L814-L821 | 12:08 |
| sean-k-mooney | so if you set that to virtio-forwarder then it will use that when creating ports | 12:08 |
| 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:09 |
| dvo-plv | I see, Could you also clarify what tests we have to execute for verification? smoke and renegade ? | 12:10 |
| sean-k-mooney | im not sure what renegade is but smoke is not enough | 12:10 |
| opendevreview | Merged openstack/nova stable/train: [compute] always set instance.host in post_livemigration https://review.opendev.org/c/openstack/nova/+/864055 | 12:10 |
| sean-k-mooney | ideally you woudl run the networkign and compute api tests and network basic ops as a minium | 12:10 |
| dvo-plv | I see, thanks | 12:11 |
| dvo-plv | Do you have some time for our blueprint with packed ring https://review.opendev.org/c/openstack/nova-specs/+/868377 ? | 12:13 |
| 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:15 |
| 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:16 |
| 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 |
| sean-k-mooney | glance images cannot be delta disk over other images | 12:17 |
| sean-k-mooney | at least not for qcow/raw images | 12:18 |
| dvo-plv | Thank you, have a good day | 12:19 |
| 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 |
| sean-k-mooney | if the storage backend supports that | 12:19 |
| opendevreview | liang jiechao proposed openstack/nova-specs master: Generic vdpa spec https://review.opendev.org/c/openstack/nova-specs/+/879338 | 12:37 |
| 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:47 |
| opendevreview | liang jiechao proposed openstack/nova-specs master: Generic vdpa spec https://review.opendev.org/c/openstack/nova-specs/+/879338 | 12:48 |
| 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:50 |
| 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:51 |
| sean-k-mooney | damnthem: https://github.com/openstack/nova/blob/29de62bf3b3bf5eda8986bc94babf1c94d67bd4e/nova/virt/libvirt/driver.py#L3286-L3369 this is the relevent code | 12:53 |
| 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:57 |
| 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 | 12:59 |
| 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:02 |
| 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:08 |
| sean-k-mooney | first we create a delat disk by using the same backing as the vm image | 13:09 |
| sean-k-mooney | this basically recreates teh state to the vm before it started runing for the first tiem | 13:10 |
| 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:11 |
| sean-k-mooney | we then freeze the guest filesystem and abort the rebase job | 13:12 |
| sean-k-mooney | instead of commiting it | 13:12 |
| sean-k-mooney | then unfreeze the filesystem | 13:12 |
| sean-k-mooney | at this point the vm is back to runing form the orginal instance disk | 13:12 |
| sean-k-mooney | and we have a copy of the filesytem changes in the delta disk | 13:13 |
| 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 |
| sean-k-mooney | then we flaten the delta disk into the final format for uploading | 13:14 |
| sean-k-mooney | and delete the delta disk | 13:14 |
| sean-k-mooney | finally we upload the image to glance. | 13:15 |
| 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:15 |
| 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 |
| sean-k-mooney | while we are doing the format convertion we need storage for the vm + deta disk + flattened image | 13:16 |
| sean-k-mooney | and after the snap shot we are just back to the orginal disk | 13:17 |
| *** Guest9758 is now known as dasm | 13:32 | |
| 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:33 |
| sean-k-mooney | damnthem: so your using raw images | 13:40 |
| sean-k-mooney | this is still useful in this case for older release as it reduces the time the mirror action takes | 13:40 |
| opendevreview | Alexey Stupnikov proposed openstack/nova master: Process unlimited exceptions raised by unplug_vifs https://review.opendev.org/c/openstack/nova/+/879350 | 14:39 |
| auniyal | Hi dansmith | 14:41 |
| dansmith | hi | 14:41 |
| auniyal | regarding this: https://review.opendev.org/c/openstack/nova-specs/+/878757 | 14:41 |
| auniyal | thanks for looking :) | 14:42 |
| auniyal | as you said, now I too think the best way to update DB is with process of restarting instnace. | 14:42 |
| auniyal | I was looking for the place where, we can updated DB, on instance shutoff. | 14:42 |
| auniyal | I think it should be in compute/api as it has stop and start functionality. | 14:42 |
| auniyal | I was also looking for list of operation nova might perform on instance shutdown or start, but could not find one. | 14:42 |
| auniyal | Is this alright to add a decorator which perform all operations on instnace shutoff | 14:43 |
| auniyal | something like | 14:43 |
| auniyal | @post_shutoff_actions | 14:43 |
| auniyal | def stop(instance): | 14:43 |
| auniyal | pass | 14:43 |
| 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 |
| dansmith | should be in manager | 14:44 |
| auniyal | at this https://opendev.org/openstack/nova/src/branch/master/nova/compute/manager.py#L3317 | 14:46 |
| 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:02 |
| auniyal | dansmith, ack, | 15:05 |
| 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 |
| auniyal | is it because this action is DB related | 15:06 |
| dansmith | no, for several reasons: | 15:08 |
| 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:08 |
| 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:09 |
| auniyal | ack, got it, | 15:11 |
| opendevreview | Alexey Stupnikov proposed openstack/nova master: Process unlimited exceptions raised by unplug_vifs https://review.opendev.org/c/openstack/nova/+/879350 | 15:37 |
| gibi | Uggla: I we we need https://review.opendev.org/c/openstack/nova/+/855664/ in train yes | 15:46 |
| gibi | Uggla: is there a complication with the backport? | 15:47 |
| Uggla | gibi, all ports should be upstream ? Any downstream to do ? | 15:47 |
| Uggla | gibi, no I just try to check the "scope". | 15:49 |
| gibi | Uggla: as we have train open upstream still we expected to land the fix upstream. | 15:57 |
| 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 |
| gibi | (we probably discuss this downstream :D) | 15:58 |
| Uggla | ok sounds good. | 15:59 |
| gibi | Uggla: thanks for picking that fix up | 15:59 |
| Uggla | gibi, you are welcome. | 16:00 |
| gibi | :) | 16:39 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!