Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-11-12
16:20:57 bauzas sharpen your pens, folks.
16:21:12 bauzas any other point ?
16:21:20 bauzas if not, let's move on
16:22:30 bauzas #topic Review priorities
16:22:38 bauzas #link https://etherpad.opendev.org/p/nova-2025.1-status
16:22:50 bauzas nothing to say more, we should have more items in the etherpad soon
16:22:57 bauzas #topic Stable Branches
16:23:03 bauzas elodilles: you're still here ?
16:23:06 elodilles yepp
16:23:10 elodilles #info stable/202*.* gates seem to be OK
16:23:25 elodilles at least, as usual, i'm not aware of any gate issue
16:23:42 elodilles and haven't seen any added to the stable CI etherpad
16:23:51 elodilles #info 2023.1 Antelope transition to 'unmaintained': https://review.opendev.org/c/openstack/releases/+/934463
16:24:12 elodilles waiting for a quick approve from the team ^^^ o:)
16:24:42 elodilles #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:24:53 elodilles please add here if you see any stable gate issue ^^^
16:25:05 elodilles and that was all from me about stable branches
16:25:17 bauzas thanks
16:26:04 bauzas I basically ack'd the Antelope unmaintained proposed patch
16:26:19 bauzas moving on
16:26:22 bauzas #topic vmwareapi 3rd-party CI efforts Highlights
16:26:26 elodilles bauzas: thx o/
16:26:32 bauzas fwiesel: anything to mention ?
16:27:38 fwiesel Not really. The master branch looks stable (only the two failures I need to fix), but there is some bug in the pipeline to fix for older releases
16:27:53 bauzas oh that's good news
16:28:00 bauzas thanks
16:28:09 bauzas I guess we can wrap then
16:28:17 bauzas #topic Open discussion
16:28:31 bauzas nothing in the agenda for today, anything anyone ?
16:29:03 bauzas looks not
16:29:05 bauzas thanks all
16:29:18 bauzas and apologies for the boring meeting, I was mostly off the first 10 mins
16:29:26 bauzas bye
16:29:28 bauzas #endmeeting
16:29:28 opendevmeet Meeting ended Tue Nov 12 16:29:28 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:29:28 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-11-12-16.00.html
16:29:28 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-11-12-16.00.txt
16:29:28 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-11-12-16.00.log.html
16:29:37 tkajinam thanks
16:29:38 elodilles thanks o/
16:33:18 fwiesel thanks o/
16:35:50 opendevreview Merged openstack/nova master: Skip functional tests on pre-commit config update https://review.opendev.org/c/openstack/nova/+/933192
18:27:42 opendevreview Artem Goncharov proposed openstack/nova master: Fix add/remove SecurityGroup action json schemas https://review.opendev.org/c/openstack/nova/+/934823
#openstack-nova - 2024-11-13
08:24:22 opendevreview Artem Goncharov proposed openstack/nova master: Fix add/remove SecurityGroup action json schemas https://review.opendev.org/c/openstack/nova/+/934823
15:28:58 opendevreview Max proposed openstack/nova master: fix: leftover BDM after instance delete https://review.opendev.org/c/openstack/nova/+/934984
15:44:49 dansmith sean-k-mooney: can you look at the osvif failure here? https://review.opendev.org/c/openstack/requirements/+/934176
15:44:57 dansmith cc frickler ^
15:53:42 tkajinam dansmith, we need https://review.opendev.org/c/openstack/os-vif/+/932436 and a new release of os-vif.
15:53:56 tkajinam but that change is blocked due to broken openstack-tox-functional-ovs-with-sudo
15:54:35 dansmith ah I didn't see a comment on that requirements patch so I didn't know
15:54:52 dansmith that requirements thing is holding up another nova fix, among other things
16:10:34 s3rj1k sean-k-mooney: Hi, was able to repro that live-migration issue with broken DNS, please see details here https://bugs.launchpad.net/nova/+bug/2086867/comments/3
16:12:53 opendevreview Merged openstack/nova-specs master: Update and Re-propose "Allow Manila shares to be directly attached to an instance when using libvirt" for Epoxy https://review.opendev.org/c/openstack/nova-specs/+/930471
16:15:24 sean-k-mooney s3rj1k: ok that not a nova bug :)
16:16:01 sean-k-mooney dansmith: i cna take a look but the the last time i looked at it a few months ago it work for me locally and i coudl not repoduce the failure
16:16:12 sean-k-mooney dansmith: so ill see if it repodcues localy now
16:16:45 sean-k-mooney s3rj1k: oh this was in relation to using the ip adress
16:17:23 sean-k-mooney s3rj1k: so have you defiend the two nova config option i noted to use the ip?
16:18:54 sean-k-mooney oh this is failing on config drive
16:19:07 sean-k-mooney this i shiti som old fallback cod ethat is not needed anymore i think
16:21:05 sean-k-mooney we used to have a workaround for old libvirt version that we have not supproted for many many years
16:21:29 sean-k-mooney where we copy the config drive in nova instead of leaving libvirt do it
16:22:26 sean-k-mooney ya this https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L11456-L11468
16:22:51 sean-k-mooney s3rj1k: so that cod ethat we can delete now, there is a patch somewhere to fix that
16:23:23 sean-k-mooney as a workaround you could use vfat config drives but we shoudl just delete that code.
16:24:00 sean-k-mooney https://review.opendev.org/c/openstack/nova/+/909122
16:24:08 sean-k-mooney s3rj1k: ^ thats the fix for your issue
16:24:42 opendevreview Doug Szumski proposed openstack/nova master: Revert "[libvirt] Live migration fails when config_drive_format=iso9660" https://review.opendev.org/c/openstack/nova/+/909122
16:24:58 s3rj1k sean-k-mooney: yea both options on both computes with corresponding IPs
16:26:45 s3rj1k hmm, https://review.opendev.org/c/openstack/nova/+/909122 will remove support for config-drive?
16:26:52 sean-k-mooney no
16:27:22 sean-k-mooney libvirt and qemu can automatically copy the iso file as part fo the live migration
16:27:38 sean-k-mooney but libvirt had a bug 8-9 years ago
16:27:46 s3rj1k ok, let me try that, I'll report back
16:27:52 sean-k-mooney and that was a tempory workaround until it could be fixed and we never reverted it
16:28:46 sean-k-mooney i think this stopped being a thing we needed to care about when we dropped ubuntu 12.04 or 14.04 support
16:31:21 sean-k-mooney s3rj1k: ah someone else already reported a similar issue to yours https://bugs.launchpad.net/nova/+bug/1939869
16:37:35 s3rj1k similar yes, fails on "Host key verification failed"
16:44:11 pas-ha[m] hi folks, today we faced what seems another fallout of those qcow-related CVE fixes. After update to latest Antelope code, some of our previously working (windows) images no longer boot (and volume can not be created). Upon closer inspection, those happened to be qcow v1 images uploaded to glance with disk_format=qcow2. This is clearly not right, yet it was working before and I wonder who else might get bitten..
16:46:54 dansmith pas-ha[m]: it was working before because glance does absolutely no inspection of images
16:47:05 pas-ha[m] from the comment in oslo.utils image format inspector, I get that this was intentional, yet I do not see that in release notes or smth.
16:47:21 pas-ha[m] yeah, I know that 🙂
16:47:28 dansmith also I suspect your images are not qcow1, but qcow2v1
16:48:04 dansmith pas-ha[m]: https://review.opendev.org/c/openstack/nova/+/928937
16:48:15 pas-ha[m] Just wanted to highlight that may be it worth mentioning that in release notes, even retro-actively
16:48:31 dansmith I wasn't planning to merge that, I mostly did it just so it was available
16:49:27 dansmith pas-ha[m]: ack, it wasn't mentioned in the release notes because most of us had assumed people had long since moved off of unsupported formats like that.. not sure we'd go back and put in a retroactive reno like that or not
16:53:32 pas-ha[m] this is tricky semantic 🙂 qemu-img calls it 'qcow' (not qcow2), calling 'file' shows 'QEMU QCOW Image (v1)'.
16:53:32 pas-ha[m] in my understanding it is really qcow == qcow v1. then came qcow v2 == qcow2 which is very different internally, and then came qcow v3 which is an extension of v2 and is backward compatible, so it is still called qcow2 file format.
16:54:31 pas-ha[m] when I tried to repro such an image, this is what you get with 'qemu-img convert -O qcow'
16:55:27 pas-ha[m] and there was QED which is even older than QCOW
16:57:32 dansmith pas-ha[m]: I'm quite sure you don't have any *actual* qcowv1 files
16:58:20 dansmith if it really is, I think we can safely say we don't intend to support your use of those
16:58:37 dansmith I know some *cough* distributions of qemu disable write support for the actual v1 format
16:59:09 pas-ha[m] as I said, this is what 'file' and 'qemu-img info' showed once I fetched files locally. I personally think someone fat fingered -O qcow2 🙂 still, came as a surprise once it broke and stopped working
17:03:16 dansmith yeah, if qemu-img is showing "file format: qcow" then you're using the ancient version that uses totally different code in qemu (as opposed to 2 and 2v3)
17:04:09 dansmith and we have never intended to support that, so I wouldn't even say we broke it.. I'd say that fits into another category of issues where you can fool nova into booting images on libvirt we intend to disallow by lying in glance
17:04:33 dansmith so this is that sort of thing, you claimed it was a v2, it's not, but we sent it to the compute node anyway and didn't notice that it's actually something other than what we expected
17:05:19 dansmith the "unintended" inspector stuff was around breaking qcow2 (vs qcow2v3) *not* about breaking the old-old format we didn't intend to support anyway
17:20:14 s3rj1k sean-k-mooney: with https://review.opendev.org/c/openstack/nova/+/909122 the actual stack trace error is gone but I still see migration failure, "Live Migration failure: Cannot recv data: ssh: Could not resolve hostname"

Earlier   Later