| opendevreview | ribaudr proposed openstack/nova master: Bump MIN_{LIBVIRT,QEMU} for "Epoxy" https://review.opendev.org/c/openstack/nova/+/942871 | 00:20 |
|---|---|---|
| opendevreview | ribaudr proposed openstack/nova master: WIP Below version constants removal for MIN_{LIBVIRT,QEMU} https://review.opendev.org/c/openstack/nova/+/942872 | 00:20 |
| dviroel | gmann: thanks for proposing the fix to 2.96 and 2.98 in tempest | 00:24 |
| gmann | dviroel: those should fix and nova documentation for 2.96, 2.98 we can fix after that | 00:28 |
| dviroel | +1 | 00:29 |
| opendevreview | Ghanshyam proposed openstack/nova master: Fix microversion 2.96 for update/rebuild APIs https://review.opendev.org/c/openstack/nova/+/942875 | 02:09 |
| opendevreview | Ghanshyam proposed openstack/nova master: Fix microversion 2.96 for update/rebuild APIs https://review.opendev.org/c/openstack/nova/+/942875 | 03:39 |
| opendevreview | Ghanshyam proposed openstack/nova master: Fix microversion 2.98 doc/tests for update/rebuild APIs https://review.opendev.org/c/openstack/nova/+/942878 | 04:53 |
| jkulik | anybody up for a review on https://review.opendev.org/c/openstack/nova/+/942371 ? it's a 2-line fix for a bug in libvirt's maxphysaddr support | 09:17 |
| gibi | jkulik: thanks for fixing that bug, if you can fix my comment in the unit test then I'm happy to +2 it | 09:22 |
| jkulik | gibi: thanks. will do | 09:22 |
| opendevreview | Johannes Kulik proposed openstack/nova master: libvirt: fix maxphysaddr passthrough dom parsing https://review.opendev.org/c/openstack/nova/+/942371 | 09:33 |
| gibi | jkulik: thanks, +2 | 09:55 |
| frickler | looks like tempest.api.compute.servers.test_create_server.ServersV294TestFqdnHostnames.test_verify_hostname_allows_fqdn is unstable, haven't seen this before https://zuul.opendev.org/t/openstack/build/4cb5f1127e464ab3b2b5cf651fd5ac9e | 10:17 |
| opendevreview | ribaudr proposed openstack/nova master: Bump MIN_{LIBVIRT,QEMU} for "Epoxy" https://review.opendev.org/c/openstack/nova/+/942871 | 10:54 |
| opendevreview | ribaudr proposed openstack/nova master: WIP Below version constants removal for MIN_{LIBVIRT,QEMU} https://review.opendev.org/c/openstack/nova/+/942872 | 10:54 |
| Uggla | sean-k-mooney[m], it you have time, can you review migration serie --> 942143: Augment the LiveMigrateData object | https://review.opendev.org/c/openstack/nova/+/942143 | 11:02 |
| sean-k-mooney | Uggla: i can see if i can fidn time i reviewd one patch breifly last night | 11:24 |
| sean-k-mooney | bauzas: can i get your advice on something. one of the things i have said i woudl do for watcher as part of the release liason role is prepare the cycle highlights and release note prelude. | 11:50 |
| sean-k-mooney | bauzas: im lookign at https://docs.openstack.org/nova/latest/contributor/ptl-guide.html#milestone-3 | 11:50 |
| sean-k-mooney | and the thing that need to be doen between m3 and rc1 | 11:50 |
| sean-k-mooney | i dont see the release note prelude in that list but do you normally base one on teh toher i.e. the prelude on the cycle highlight and vise versa | 11:51 |
| sean-k-mooney | is there anything that is easy to miss doing that is time sensive that you would call out | 11:52 |
| sean-k-mooney | watcher does not have a equivalent doc so im probely goitn go steal nova and updte it a lltie with a new title and add it to watcher after the release | 11:59 |
| sean-k-mooney | "Chronological Release Milestone guide" or soemthing like that | 12:00 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Add new option to enforce multipath volume connections https://review.opendev.org/c/openstack/nova/+/845660 | 12:14 |
| tkajinam | Does anyone have time to review this tiny cleanup https://review.opendev.org/c/openstack/nova/+/939027 ? | 12:16 |
| tkajinam | stephenfin, thanks ! | 12:20 |
| sean-k-mooney | yep looks good | 12:22 |
| sean-k-mooney | we will want to add 3.13 early next cycle | 12:22 |
| stephenfin | and hopefully remove 3.9 | 12:24 |
| tkajinam | hopefully though you may have to make sure that c9s is fully replaced by c10s in RDO | 12:25 |
| stephenfin | indeed | 12:25 |
| tkajinam | IIRC python 3.9 is the system python in c9s | 12:25 |
| sean-k-mooney | 3.9 cant be removed until 2026.1 | 12:26 |
| sean-k-mooney | we need to support both c9s and c10s in 2025.2 for upgrades | 12:26 |
| tkajinam | you can make 2025.1 as the pivot between c9s and c10s I guess | 12:27 |
| sean-k-mooney | no becuase it was not aviable at the start of the 2025.1 cycle | 12:27 |
| tkajinam | as we did for train | 12:27 |
| tkajinam | which may be better given some people may try direct upgrade from 2025.1 to 2026.1 | 12:27 |
| sean-k-mooney | so its not in the officl testing runtimes for this release | 12:27 |
| tkajinam | yeah that's the problem | 12:27 |
| sean-k-mooney | the first tiem c10s can be added is 2025.2 | 12:27 |
| tkajinam | there may be number of things we have to address such as redis->valkey | 12:28 |
| sean-k-mooney | the other issus is | 12:28 |
| sean-k-mooney | c10s is built with the x86_64v4 profile in gcc | 12:28 |
| sean-k-mooney | meaning it wont run on the old rackspace cloud provider | 12:28 |
| sean-k-mooney | so we will need to restrict the node set ot vexhost and the newer rax-flex cloud | 12:29 |
| sean-k-mooney | maybe ovh but that will need testing to confirm | 12:29 |
| stephenfin | sean-k-mooney: Could you look at https://review.opendev.org/c/openstack/placement/+/932399 and its predecessor? | 12:29 |
| tkajinam | another fun transition :-P | 12:29 |
| sean-k-mooney | oh finally yes | 12:29 |
| tkajinam | I was only aware of complete migration to nmcli as a blocker. that's a good thing to know. | 12:30 |
| sean-k-mooney | stephenfin: i tought i had a patch for this but your has a +2 so i dont even care if it id :) | 12:30 |
| sean-k-mooney | stephenfin: hehe ya i did https://review.opendev.org/c/openstack/placement/+/899947 | 12:31 |
| stephenfin | yup, and they both failed due to https://review.opendev.org/c/openstack/devstack/+/919581 | 12:32 |
| stephenfin | or rather, because https://review.opendev.org/c/openstack/devstack/+/919581 wasn't in yet | 12:32 |
| stephenfin | sean-k-mooney: wdywtd? I'm happy with either, seeing as they're identical | 12:32 |
| sean-k-mooney | i already appoved yours | 12:33 |
| stephenfin | ack | 12:33 |
| stephenfin | sean-k-mooney: You're going to need to review https://review.opendev.org/c/openstack/placement/+/939637 too, I suspect, otherwise the py312 tests will fail | 12:34 |
| sean-k-mooney | ... droping '' form the message | 12:36 |
| sean-k-mooney | ok | 12:36 |
| sean-k-mooney | we might want ot rewrite that test but teh current fix is ok | 12:37 |
| tkajinam | stephenfin, do you have a min to review https://review.opendev.org/c/openstack/nova/+/939721 ? | 12:39 |
| tkajinam | I thought I proposed it but I didn't it seems | 12:39 |
| stephenfin | ack, done | 12:41 |
| tkajinam | stephenfin, and another cleanup related to oslo https://review.opendev.org/c/openstack/nova/+/940619 | 12:42 |
| tkajinam | stephenfin, thanks ! | 12:42 |
| opendevreview | zhou zhong proposed openstack/nova master: Logging exception when query servers for further debug https://review.opendev.org/c/openstack/nova/+/942897 | 12:49 |
| opendevreview | zhou zhong proposed openstack/nova master: Logging exception when query servers for further debug https://review.opendev.org/c/openstack/nova/+/942897 | 12:53 |
| opendevreview | zhou zhong proposed openstack/nova master: Logging exception when query servers for further debug https://review.opendev.org/c/openstack/nova/+/942897 | 12:55 |
| sean-k-mooney | tkajinam: by the way i had hoped to check in on your sev series earlier in the cycle but just never found time | 13:15 |
| sean-k-mooney | tkajinam: i dropped my -1 adn agree with your arguemnt on defaulting to sev at least for now | 13:15 |
| sean-k-mooney | tkajinam: i dont feel confidnet in being able to review it before FFs | 13:15 |
| sean-k-mooney | tkajinam: but i would supprot tryign to focus on this early next cycle | 13:16 |
| tkajinam | sean-k-mooney, thank you ! | 13:18 |
| sean-k-mooney | just level settign with folks. while im not there yet im gettign close to my context swtiching limit so i likely wont have tiem to do many more reviews today at least not until i take a short break to reset | 13:33 |
| sean-k-mooney | i see two feature that are clsoe to mergign that we might be able to get over the line | 13:34 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/938604 and https://review.opendev.org/c/openstack/nova/+/938405 | 13:34 |
| sean-k-mooney | so schduler hints in server show and the managed flag for pci passhtough | 13:34 |
| sean-k-mooney | i will try to look at the follow up for pci live migratoin however im not sure ill have time to properly review that today but ill try | 13:35 |
| gibi | ack | 13:36 |
| gibi | the managed flag is approved going through the gate, the live-migratable series is under review by my at the moment | 13:36 |
| sean-k-mooney | im too cold on the vtpm serices to meanining fully look at that today and honetly it has enough WIP patches that i dont think it viable currently | 13:37 |
| sean-k-mooney | is there anything else i shoudl have on my radar or do you think those 3 are it | 13:38 |
| sean-k-mooney | i dont consider bumping the min libvirt version to be a feature https://review.opendev.org/c/openstack/nova/+/942871 so i think that can merge between FF and rc1 | 13:39 |
| sean-k-mooney | so im treating that as a lower priority | 13:39 |
| gibi | yeah I think vtpm slips to F | 13:40 |
| sean-k-mooney | ok im going to step away for 20 mins then and ill try an take a look at the migration series when i return | 13:40 |
| gibi | while there are some raw edges in the live-migratable series it feels pretty close to me. I don't know how much brainpower bauzas has to look at that today | 13:41 |
| bauzas | gibi: I'll look at it after some meeting | 13:48 |
| gibi | ack (sending good wibes) | 13:48 |
| tkajinam | I know everyone is busy but if you can spare some moments to review this specless bp then that'd be awesome https://review.opendev.org/c/openstack/nova/+/845660 | 13:57 |
| tkajinam | I just rebased it to make sure it works with the latest code and likely need to leave before CI posts the latest result | 13:57 |
| bauzas | tkajinam: my hard effort for today will be to purge the status etherpad and you're part of it :) | 13:58 |
| tkajinam | \o/ | 13:58 |
| tkajinam | this conflicts with the sev-es patches but I'm fine with pushing the sev-es work to next cycle and let that multipath change go first, given the complexity of sev-es series | 14:00 |
| bauzas | thanks for telling the priorities | 14:01 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Add new option to enforce multipath volume connections https://review.opendev.org/c/openstack/nova/+/845660 | 14:26 |
| tkajinam | os-brick made a breaking interface change and that is part of the latest release. ugh | 14:29 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Add new option to enforce multipath volume connections https://review.opendev.org/c/openstack/nova/+/845660 | 14:37 |
| sean-k-mooney | tkajinam: looks like its small enough to add to the review list | 15:01 |
| sean-k-mooney | for today | 15:01 |
| sean-k-mooney | but i guess we will see | 15:01 |
| sean-k-mooney | tkajinam: +2 with comments | 15:15 |
| dansmith | tkajinam: I had a couple comments but didn't -1 | 15:16 |
| dansmith | tkajinam: if you fix them I'll be +2+W | 15:16 |
| bauzas | tkajinam: I have one concern https://review.opendev.org/c/openstack/nova/+/845660/15/nova/virt/libvirt/driver.py#1177 | 15:19 |
| sean-k-mooney | dansmith: replied im not agaisnt InvalidConfiguration but it think its subtlly diffent | 15:19 |
| bauzas | tkajinam: you were litterally speaking about how os-brick can break some API by a new major version, I'm a bit afraid of us pulling a hard dependency on some osbrick submodule at some driver initialization | 15:20 |
| sean-k-mooney | dansmith: so if its updated im ok with that but i generally think of InvalidConfiguration as stricly configuring conflicting options or missign requried ones based on the current set values | 15:20 |
| sean-k-mooney | dansmith: but i dont think i would be confused if this was InvalidConfiguration as an operator either | 15:21 |
| dansmith | sean-k-mooney: I replied | 15:22 |
| dansmith | bauzas: only if multipathd is configured as required and you could sidestep that problem by changing it to not if you had to for a package conflict | 15:22 |
| dansmith | bauzas: to me, the more of this kind of stuff we delegate to brick (no matter where it is in their module hierarchy) the better | 15:23 |
| dansmith | if they break their api and thus us, then so be it, like any other library | 15:23 |
| bauzas | dansmith: sure, that's not the fact that we delegate to brick at startup | 15:23 |
| bauzas | that's about calling a specific brick connector module to get that | 15:23 |
| dansmith | it's that it's using a given driver | 15:24 |
| sean-k-mooney | we also dont have a connecto obejct to use | 15:24 |
| bauzas | while connectors do that already | 15:24 |
| dansmith | sure, but the only thing that would break that should be a requirements change | 15:24 |
| sean-k-mooney | we woud need to constract athat for a given voluem first | 15:24 |
| bauzas | tbc, I haven't -1 the patch | 15:24 |
| sean-k-mooney | bauzas: what i would prefer to do is add a privsep funciton in nova that just does what the current so brick funtion does | 15:24 |
| bauzas | but I'm debating the alternatives, since I'm not at all a brick expert | 15:25 |
| dansmith | sean-k-mooney: I'm very -1 on that | 15:25 |
| bauzas | sean-k-mooney: sorry but I'm like dan | 15:25 |
| sean-k-mooney | well i just dont like having to constuct rootwap calls | 15:25 |
| sean-k-mooney | in nova | 15:25 |
| bauzas | I don't want nova to do brick things | 15:25 |
| dansmith | sean-k-mooney: when brick gets changed because multipathd changes, we'll never update our copy and we'll break | 15:25 |
| dansmith | that's a terrible idea, IMHO | 15:25 |
| sean-k-mooney | if there was a high level fonction that didnt need that it woudl be fine | 15:25 |
| dansmith | bauzas: right, this is brick's domain, even if it's ugly | 15:25 |
| bauzas | that's my point | 15:25 |
| bauzas | I'm ok with calling brick | 15:25 |
| sean-k-mooney | i dont have an issue using brick | 15:25 |
| bauzas | I'm a bit torn with calling brick on a specific subdomain | 15:26 |
| sean-k-mooney | i just dislike that we have to do the utils.get_root_helper() part | 15:26 |
| dansmith | sean-k-mooney: oh you want to privsep wrap the brick call? that's different than what you suggested | 15:26 |
| bauzas | sean-k-mooney: https://github.com/openstack/os-brick/blob/6e83ac6eeee8f3a4b3265a4e927dca1bc190e088/os_brick/initiator/connectors/iscsi.py#L523 | 15:26 |
| bauzas | we could just call supports_multipath | 15:27 |
| sean-k-mooney | dansmith: no i want brick to update the fucntio to use prvisep internall | 15:27 |
| sean-k-mooney | and we just call it | 15:27 |
| bauzas | that's what I wrote in my comment | 15:27 |
| dansmith | bauzas: that's a connector object though | 15:27 |
| bauzas | instead of using what looks to me an internal brick API | 15:27 |
| bauzas | dansmith: doesn't it doing the same thing ? | 15:27 |
| sean-k-mooney | bauzas that need us to constuct a connector which whil we could proably fake normlay need connection info form cinder | 15:28 |
| dansmith | sean-k-mooney: okay that's fine, but.. don't we call brick things all over the place? are they all wrapped in privsep? | 15:28 |
| bauzas | ah | 15:28 |
| sean-k-mooney | dansmith: no | 15:28 |
| dansmith | bauzas: we don't have a connector object though.. and we wouldn't here | 15:28 |
| dansmith | sean-k-mooney: which no? :) | 15:28 |
| sean-k-mooney | i was punting on that i just wanted a commnt to be added to know we need to clean this up in the future | 15:28 |
| bauzas | I wish we had then a more abstract API to consume | 15:28 |
| bauzas | but I'm cool with merging it as it is, provided we document it may break :) | 15:29 |
| dansmith | sean-k-mooney: comment works :) | 15:29 |
| bauzas | heh, jinxed | 15:29 |
| sean-k-mooney | i was ok if not supper happy with multipath_running = linuxscsi.LinuxSCSI.is_multipath_running ... | 15:29 |
| sean-k-mooney | a comment woudl be nice i just didnt want to ask for a respin for that | 15:29 |
| dansmith | bauzas: I don't think that's a private brick api | 15:29 |
| sean-k-mooney | on its own | 15:29 |
| dansmith | bauzas: it's underscored in the connector usage, but it's api is not underscored | 15:30 |
| bauzas | you're right | 15:30 |
| bauzas | anyway, I'm cool with shipping as it is, hence my +1 but I'd appreciate if we could comment out that call | 15:30 |
| bauzas | comment s/out// | 15:30 |
| bauzas | (english and all your adverbs) | 15:31 |
| sean-k-mooney | tkajinam: so tl;dr dansmith was right and if you adress there intial comemnts i think we are all ok with your patch | 15:35 |
| dansmith | sean-k-mooney: just to circle back.. I'm not sure InvalidConfiguration should really inherit from Invalid, but raising Invalid itself defaults to "400 Bad Request" because that's really for HTTP Invalid.. I know he's overriding the message, | 15:35 |
| dansmith | but it's just not what Invalid should be used for, IMHO | 15:35 |
| sean-k-mooney | your right i was orgianly considerign if it shoudl be a RuntimeError but decied not to suggest that | 15:36 |
| sean-k-mooney | partly because i was nto sure RuntimeError woudl abort startup | 15:36 |
| dansmith | yeah, RuntimeError is interesting, but I tend to think that's more useful for things like "This shouldn't happen" .. programming errors more than something the operator could have done | 15:37 |
| dansmith | anyway, it's all a bit pedantic anyway | 15:37 |
| sean-k-mooney | to me that is what the second test really is, the config is valid but the runtime depency is not met. so either this should be some kind of custome excpetion or we use `InvalidConfiguration` adn agree that you were right before you confince me otherwise :) | 15:38 |
| sean-k-mooney | s/confince/convince/ | 15:38 |
| * dansmith takes the W | 15:38 | |
| masahito | hi nova folks, could you review the API bug fix? https://review.opendev.org/c/openstack/nova/+/939658 It needs +W now. | 15:54 |
| jizaymes | Hello. I made the mistake of trying to rebuild my linux images for openstack (2024.2) to add qemu-agent baked in -- that worked but couldn't SSH in. I then reverted my images to the vanilla ubuntu cloud images (tried 22 and 24, no customization.) In all cases now, cloud-init sets the IP and dns servers, etc, but no longer injects the ssh key for the ubuntu user. I ran the image separately on a kvm box with a cloud-init .iso I made and it | 16:47 |
| jizaymes | processed that correctly and added the ubuntu user ssh authorized key, but somehow the functionality within nova is now not working. no clear log events in the neutron-ovn-metadata service logs or nova logs. Recommendations? | 16:47 |
| opendevreview | Doug Szumski proposed openstack/nova master: Stop corrupting ephemeral volumes during cold migration https://review.opendev.org/c/openstack/nova/+/940900 | 16:58 |
| jizaymes | seems to match this thread, but I am not sure what their resolution was https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/XPHA7B5D6SIZZPLXT7CLLXX5OHYPTYSW/#XPHA7B5D6SIZZPLXT7CLLXX5OHYPTYSW | 17:08 |
| dougszu | sean-k-mooney: I've had a go at removing the ephemeral volume backing file in the above patch - it doesn't seem too bad. Any thoughts when you've got a moment would be great | 17:13 |
| sean-k-mooney | dougszu: skiming it, ack on updating to also ensure new vms dont have backing files for ephmeeral, (it sould also be done for swap) today is feature freeze (upstream and a seocnd one downstream) so im kind of maxed out on reviews currently | 17:21 |
| sean-k-mooney | dougszu: i can try and take a look at this next week dougszu feel free to ping me about it | 17:21 |
| dougszu | many thanks! will do | 17:22 |
| sean-k-mooney | live migration is harder so one appoch would be to do that in a diffent patch. | 17:22 |
| sean-k-mooney | focus this on new vms (inculding unshelve) and cold migrate/rezise | 17:23 |
| sean-k-mooney | if we flattened images on hard reboot | 17:23 |
| sean-k-mooney | or agent restart that might also be an option | 17:23 |
| sean-k-mooney | everngly all vms would not have backign files for ephmeral and swap and so live migrate woudl eventurally resolve | 17:24 |
| sean-k-mooney | thats kind of a cop out but | 17:24 |
| sean-k-mooney | incremental progress is still better then none | 17:24 |
| dougszu | yeah - I've tested that, it's a path at least | 17:24 |
| dougszu | thanks for the pointers | 17:24 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Adjust validation helpers for a single-method future https://review.opendev.org/c/openstack/nova/+/936365 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Stop using wsgi.Controller.api_version to switch between API versions https://review.opendev.org/c/openstack/nova/+/936366 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Only check minimum API version https://review.opendev.org/c/openstack/nova/+/940325 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add new, simpler api_version decorator https://review.opendev.org/c/openstack/nova/+/936367 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Only run format checks on strings https://review.opendev.org/c/openstack/nova/+/936368 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Simplify parameter types https://review.opendev.org/c/openstack/nova/+/936369 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: tests: Ensure all APIs have a response body schema https://review.opendev.org/c/openstack/nova/+/924598 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: doc: Add missing API samples https://review.opendev.org/c/openstack/nova/+/937012 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: project/tenant and user IDs are not UUIDs https://review.opendev.org/c/openstack/nova/+/940369 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for hosts APIs https://review.opendev.org/c/openstack/nova/+/937047 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for instance actions https://review.opendev.org/c/openstack/nova/+/937048 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for hypervisors APIs (1/3) https://review.opendev.org/c/openstack/nova/+/937245 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for hypervisors APIs (2/3) https://review.opendev.org/c/openstack/nova/+/937246 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for hypervisors APIs (3/3) https://review.opendev.org/c/openstack/nova/+/937247 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for server IPs APIs https://review.opendev.org/c/openstack/nova/+/937608 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for remote consoles https://review.opendev.org/c/openstack/nova/+/940114 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for keypairs APIs https://review.opendev.org/c/openstack/nova/+/940115 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for image metadata APIs https://review.opendev.org/c/openstack/nova/+/940299 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for server topology API https://review.opendev.org/c/openstack/nova/+/940300 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for server diagnostics API https://review.opendev.org/c/openstack/nova/+/940506 | 17:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for server external events API https://review.opendev.org/c/openstack/nova/+/940508 | 17:50 |
| bauzas | gmann: https://review.opendev.org/c/openstack/nova/+/942875 is a bugfix, so it won't be impacted by the FF | 18:06 |
| gmann | bauzas: yeah, bug fix for documentation only and not in the code. At least it is to match the code change (done intentionally or unintentionally ) with documentation unless anyone object not to have any change in update server API response which is not discussed in the spec or original implementation. | 18:09 |
| gmann | bauzas: but we want to change update server response also which is done in the original code change and in my change I am matching the documentation (api-ref, tests, releasenotes etc) accordingly | 18:10 |
| gmann | bauzas: ditto for the https://review.opendev.org/c/openstack/nova/+/942875/2 also | 18:11 |
| gmann | I found it when reviewing the 2.100 microversion https://review.opendev.org/c/openstack/nova/+/938604 | 18:11 |
| gmann | also fixing the tempest test/schema also for those microversion https://review.opendev.org/c/openstack/tempest/+/942870 | 18:11 |
| opendevreview | Ghanshyam proposed openstack/nova master: Fix microversion 2.96 for update/rebuild APIs https://review.opendev.org/c/openstack/nova/+/942875 | 18:12 |
| opendevreview | Ghanshyam proposed openstack/nova master: Fix microversion 2.98 doc/tests for update/rebuild APIs https://review.opendev.org/c/openstack/nova/+/942878 | 18:12 |
| bauzas | nova-cores, I eventually give an extra 3 days (until Thursday) for merging implementation that already got one +2 | 18:15 |
| bauzas | please see https://etherpad.opendev.org/p/nova-2025.1-status for the current state of exceptions | 18:15 |
| gibi | until Tuesday or Thursday? | 18:17 |
| gmann | yeah, I am also holding this to approve in case FFE things here https://review.opendev.org/c/openstack/nova/+/938604 | 18:17 |
| gmann | bauzas: can you write the date also along with Tuesday/day so that it will be clear | 18:18 |
| gmann | I saw this and not clear which tuesday https://etherpad.opendev.org/p/nova-2025.1-status#L73 | 18:18 |
| gmann | sorry this one https://etherpad.opendev.org/p/nova-2025.1-status#L84 | 18:18 |
| gmann | 'show-scheduler-hints-in-server-details' | 18:18 |
| gmann | bauzas: added these two microversion doc bug fixes detail in etherpad under 'Feature Complete With Follow Up Pending' https://etherpad.opendev.org/p/nova-2025.1-status | 18:31 |
| sean-k-mooney | gmann: feature freeze is today | 18:35 |
| sean-k-mooney | not tuesday | 18:35 |
| sean-k-mooney | which is why i was hopign we could proceed with https://review.opendev.org/c/openstack/nova/+/938604 | 18:36 |
| gmann | sean-k-mooney ok its today right not next thursday? | 18:36 |
| sean-k-mooney | ill check again | 18:36 |
| sean-k-mooney | maybe im off by a week | 18:36 |
| gmann | days are confusing there, having date will be more clear | 18:36 |
| sean-k-mooney | https://releases.openstack.org/epoxy/schedule.html#epoxy-3-milestone | 18:37 |
| sean-k-mooney | February 27, 2025 i | 18:37 |
| sean-k-mooney | so today | 18:37 |
| gmann | I asked bauzas just to be more clear | 18:37 |
| stephenfin | Uggla: fyi, you probably want to respin https://review.opendev.org/c/openstack/openstacksdk/+/880056 soon enough if that's intended for this release | 18:37 |
| sean-k-mooney | gmann: nova observes the unifed feature freeze with is milesotone 3 which is today February 27, 2025 | 18:37 |
| gmann | sean-k-mooney: ohk, great then we are on perfect time for 938604 | 18:38 |
| sean-k-mooney | ya so we normally allow things that are +w to merge up until the next irc meeting | 18:38 |
| Uggla | Hi stephenfin, I'd like to. But I'm unsure I'll find time to do it. :( | 18:39 |
| sean-k-mooney | so if its approved by close of buisness PST | 18:39 |
| sean-k-mooney | then we consider it in for FF | 18:39 |
| sean-k-mooney | even if it only merges at the weekend | 18:39 |
| gmann | yeah, just +W on that | 18:39 |
| stephenfin | Guess it's for next cycle so. You'll just have to remember to backport it if you need it downstream | 18:39 |
| Uggla | stephenfin, unfortunately yes. But my current prio is on VFIO PCI live migration. | 18:42 |
| gmann | sean-k-mooney: these two microversion doc bug fixes are also up, it pass the CI but I fix one thing/rebased so you can wait until gate is green https://review.opendev.org/c/openstack/nova/+/942875 https://review.opendev.org/c/openstack/nova/+/942878 | 18:43 |
| gmann | I *fixed* one thing | 18:44 |
| sean-k-mooney | i saw the first one this morning but didnt review it yet | 18:45 |
| gmann | k] | 18:46 |
| sean-k-mooney | those are not subject to FF and can merge up to RC1 although the first we should backprot to stable | 18:46 |
| gmann | cool | 18:46 |
| sean-k-mooney | i think 2.96 was last cycle | 18:46 |
| sean-k-mooney | oh it was carical | 18:47 |
| sean-k-mooney | so 2024.1 | 18:47 |
| gmann | yeah, that we need to backport https://github.com/openstack/nova/blob/stable/2024.2/nova/api/openstack/compute/rest_api_version_history.rst#296-maximum-in-20241-caracal-and-20242-dalmatian | 18:47 |
| gmann | will do that once master change is merge | 18:48 |
| sean-k-mooney | if i try to review it now i think ill jsut miss things, im sure its correct but ill try an look at this tomorrow | 18:48 |
| gmann | thanks | 18:50 |
| opendevreview | ribaudr proposed openstack/nova master: Update manager to allow vfio pci device live migration https://review.opendev.org/c/openstack/nova/+/942145 | 19:44 |
| opendevreview | ribaudr proposed openstack/nova master: Update conductor and filters allowing migration with SR-IOV devices https://review.opendev.org/c/openstack/nova/+/942146 | 19:44 |
| opendevreview | ribaudr proposed openstack/nova master: Update driver to map the targeted address for SR-IOV PCI devices https://review.opendev.org/c/openstack/nova/+/942147 | 19:44 |
| sean-k-mooney | Uggla: i reviewed some of the series and left comments. im not sure what persecnetage fo those have been adressed in ^ if any but even with the extention bauzas is proposing im not sure we should merge the live migration part this cycle | 19:53 |
| sean-k-mooney | ill try an take a look at this again tomorrow | 19:53 |
| sean-k-mooney | but since we do not have tempest testing for this the funcitonal test weill need to be pretty exaustive | 19:53 |
| sean-k-mooney | and i dont want ot merge any of the migration series until we are +2 on all the patches | 19:54 |
| opendevreview | Merged openstack/nova master: Drop environment for Python 3.8 https://review.opendev.org/c/openstack/nova/+/939027 | 20:23 |
| Callum027 | Hi there, yesterday I published a blueprint (https://blueprints.launchpad.net/nova/+spec/xml-image-meta) and patch (https://review.opendev.org/c/openstack/nova/+/942766) for implementing adding image_meta metadata to the libvirt XML for downstream services (primarily Ceilometer) to consume. I'd appreciate some feedback on the design of the XML and | 20:44 |
| Callum027 | the patch itself if a core reviewer has free time to do so. Thanks! | 20:44 |
| sean-k-mooney | Callum027: so what your propsoing is someitng i started workign on a year or two ago and then never had time to get back too | 22:53 |
| sean-k-mooney | Callum027: i have some idea of what i would like to include if we extend the metadta futher | 22:53 |
| sean-k-mooney | notable we currenly store some metadata about the image and falvor but we dont express that consitently in the xml | 22:54 |
| sean-k-mooney | so if we do enchnce this i woudl liek to try and encode both consistently i.e. provide both the name and uuid for the flavor and image | 22:55 |
| sean-k-mooney | provdrive the extra specs and properties for both | 22:55 |
| Callum027 | Hi sean-k-mooney, interesting, got any links to what you proposed earlier? | 22:56 |
| sean-k-mooney | kind of so we had a converation with the ironic folk about the fact that they wanted simialr metadat for ther own usage. | 22:57 |
| sean-k-mooney | so i did a poc of factoring out the metadat functions https://review.opendev.org/c/openstack/nova/+/905406 which we combiend with there work | 22:58 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/923910/5/nova/virt/driver.py#49 | 22:58 |
| sean-k-mooney | and ^ were the calsess we ended up with | 22:58 |
| sean-k-mooney | what i didnt end of pocign was basiclly the changes to print all fo the files in the xml | 22:59 |
| sean-k-mooney | so for image you see it has id name and propereis | 22:59 |
| sean-k-mooney | in my orginal poc i also had id name and "extra_specs" for flavor https://review.opendev.org/c/openstack/nova/+/905406/2/nova/virt/driver.py | 23:00 |
| sean-k-mooney | so some of those files were doped in the version we merged because ironic didnt need them | 23:00 |
| sean-k-mooney | Callum027: so lookign at my local git repo i dont seem to have my poc for extending the xml and i do not see it on gerrit either | 23:03 |
| sean-k-mooney | so either i didnt commit it or i did but didnt push it anywaher | 23:03 |
| sean-k-mooney | Callum027: lookign at your patch | 23:04 |
| sean-k-mooney | you seam to be extendign the ground work we created 6 months ago | 23:04 |
| sean-k-mooney | Callum027: its kidn fo funny because the value your addign are once i intetally was not going to incldue for image | 23:05 |
| sean-k-mooney | to me the image prorpees were the most valueabel rather then min_(ram/disk) or the format | 23:06 |
| opendevreview | Merged openstack/placement master: doc: Use dnf instead of yum https://review.opendev.org/c/openstack/placement/+/938499 | 23:06 |
| opendevreview | Merged openstack/nova master: doc: Use dnf instead of yum https://review.opendev.org/c/openstack/nova/+/938496 | 23:06 |
| Callum027 | seak-k-mooney: Yeah they are, the properties are what I actually want, but since they're included in image_meta by Nova notifications and Ceilometer uses them I thought it was a good idea to include them | 23:07 |
| sean-k-mooney | Callum027: whiel at the saem time your not including the name or id | 23:07 |
| Callum027 | Actually, I don't think min_ram etc are actually used by Ceilometer out of the box but why not I thought | 23:07 |
| sean-k-mooney | so part of the reason i didnt spend too much time on this before beyond the fact i was busy with other things | 23:08 |
| sean-k-mooney | is i knwo some of the nova core are concerned with not makign the metadta too log | 23:08 |
| sean-k-mooney | on the ohter hand i have spend enough days of my life in extra debuging time trying to diagnose customer issues | 23:08 |
| sean-k-mooney | where having this info would have made it seconds | 23:09 |
| sean-k-mooney | so i think ther is value in provide at least some of it in the xml | 23:09 |
| sean-k-mooney | Callum027: you have impleted it very close to how i woudl have done it so im mostly supprotive of this propsoal | 23:11 |
| sean-k-mooney | Callum027: are you famialr with our process for proposing new features? | 23:11 |
| Callum027 | I'm afraid not no | 23:11 |
| sean-k-mooney | well the first step is generally either ot propose a blueprint or ask about adding the enhancement on irc or the mailing list | 23:12 |
| sean-k-mooney | today is actully Feature Implemation Freeze for the 2025.1 release | 23:13 |
| sean-k-mooney | so we are entring a code freeze period for about 2 week until the first release candiate for 2025.1 is created and then master reopens for development | 23:13 |
| sean-k-mooney | Callum027: when a blueprint is proposed we useally ask the propsoer to bring it up in our next irc meeting to ask the wider core team to approve it as a specless bluepirnt | 23:14 |
| sean-k-mooney | or if we think it need more detailed deicsion we may ask for a spec docuemnt | 23:14 |
| sean-k-mooney | in this case i think it could be a specless blueprint but we will have to see how other feel | 23:15 |
| sean-k-mooney | Callum027: also as we are at the end of one release syscycle and will be starting another shortly | 23:16 |
| sean-k-mooney | we will have a virtual comunity event call the PTG (project teams gattering) april 7-11th | 23:16 |
| sean-k-mooney | Callum027: so if there was not agreement on this and you wanted a higher bandwith venue to disucss it it could be dicussed there | 23:16 |
| sean-k-mooney | Callum027: ah i just check you have contibuted to ceilometer and adjusat before | 23:17 |
| sean-k-mooney | Callum027: so you are proably familar with the general flow. | 23:17 |
| Callum027 | I have made contributions to Ceilometer and Adjutant before but mainly smaller patches to add features or fix issues that didn't require more fundamental changes to things like file formats | 23:19 |
| Callum027 | So this explanation was very helpful, thank you | 23:19 |
| sean-k-mooney | Callum027: based on https://review.opendev.org/c/openstack/ceilometer/+/942879 i take it yoru usecase for this is to consuem it in ceilometer and then publish the metadat to a telemetery backend of some kind? | 23:19 |
| sean-k-mooney | Callum027: may i ask what is the end goal that this enables | 23:21 |
| Callum027 | Yes, in particular we're working on an OpenStack billing service that takes telemetry and metadata submitted to Gnocchi by Ceilometer, one of the things we're billing for requires image metadata from the instance. *Just* relying on Nova notifications to supply this is not good enough, we want it in the libvirt XML metadata so Ceilometer's pollsters | 23:21 |
| Callum027 | can provide this information as well. | 23:21 |
| sean-k-mooney | ah ok | 23:21 |
| sean-k-mooney | part of the reason i ask is i ahve recnetly been workign a bit on watcher | 23:22 |
| sean-k-mooney | we ahve been addign the ablity to pull data form prometeous (and we have celomiter metrics feeding into promethous) | 23:22 |
| sean-k-mooney | Callum027: so i was trying to decied if this would be useful in that context | 23:22 |
| sean-k-mooney | watcher also has the ablity to consume the novaificaton but i was trying to decied if there was any benifit in consuming this info via the metrics form ceilometer | 23:23 |
| Callum027 | For us anyway there are benefits. The main issue is the reliability of Nova's notifications. For existing instances that are not changed frequently, Nova only sends out a compute.instance.exists notification once per hour or so. If Ceilometer fails to consume that notification for one reason or another from RabbitMQ, the sample metadata is not | 23:25 |
| Callum027 | published to Gnocchi. | 23:25 |
| sean-k-mooney | well notificatoin are really ment to be fire and forget | 23:25 |
| sean-k-mooney | they are not inteded as a reliable message deliveray mechanium | 23:26 |
| sean-k-mooney | so ya i can see why that would nto be ideal for billing | 23:26 |
| Callum027 | Yes, and for billing we want to accurately know the state of the resource at the time it was polled | 23:26 |
| Callum027 | Otherwise we're not billing correctly | 23:26 |
| sean-k-mooney | ya makes sesne. so next steps, RC1 is planed for 2 weeks time | 23:27 |
| sean-k-mooney | the week after that will be the first irc meetign of the 2025.2 development cycle | 23:28 |
| sean-k-mooney | that would be yoru first real opertunity to ask for the spec to be approved | 23:28 |
| sean-k-mooney | *bluepirnt to be approved | 23:28 |
| Callum027 | Alright, sounds good, so the meeting for the week of 17-23 March? | 23:29 |
| sean-k-mooney | yes im not sure if this time https://meetings.opendev.org/#Nova_Team_Meeting suits you | 23:30 |
| sean-k-mooney | if not you can ask for the blueprint to be approved on the mailing list | 23:30 |
| Callum027 | Tuesday 1600 UTC is Wednesday 0700 NZDT so I should be okay for that | 23:31 |
| Callum027 | In the meantime I'm happy to make any suggestions/additions you think would make the proposal fit your use case better | 23:31 |
| sean-k-mooney | if its too early you can also just add the bluepirint to the adjeda and we will discss it without you | 23:31 |
| sean-k-mooney | basifclly there is an open dicusstion section here https://wiki.openstack.org/wiki/Meetings/Nova | 23:32 |
| sean-k-mooney | Callum027: the process to ask for it to be approved is too just add a secion with yoru name and link to it and a line or two about what it is and whay you want to enable it | 23:32 |
| sean-k-mooney | Callum027: you have already done a pretty good job of descibing it in https://blueprints.launchpad.net/nova/+spec/xml-image-meta | 23:33 |
| sean-k-mooney | Callum027: in term fo feed back i am not sure when ill have time to review the patch next but ill try and leave some comments on the review | 23:33 |
| Callum027 | Awesome, thank you. Should I add the topic to the agent on the week of the first meeting for 2025.2 development, or is now fine? | 23:34 |
| Callum027 | agenda* | 23:34 |
| Callum027 | I should be able to be there at the meeting time as well | 23:35 |
| sean-k-mooney | so you could add it now but it will come up next tuseday and we will proably be too busy with feature feeze stuff | 23:35 |
| sean-k-mooney | so you coudl see but we might say lets wait until we are doen with 2025.1 first | 23:35 |
| Callum027 | Sounds good! | 23:36 |
| sean-k-mooney | just looking at this in the ci | 23:37 |
| sean-k-mooney | https://zuul.opendev.org/t/openstack/build/aeae5e9ef4c042fb89555623e3be9466/log/controller/logs/screen-n-cpu.txt#9620 | 23:37 |
| sean-k-mooney | it loosk pretty reasonabel but if you look at the falvor vs the image you see the flavor has naem and the image has the uuid but in a sub element | 23:38 |
| sean-k-mooney | that the relevent part https://paste.opendev.org/show/bbHRV4uzP2yZr8j7yPEW/ | 23:41 |
| sean-k-mooney | if i was to update it i would modify it slightly | 23:41 |
| sean-k-mooney | we currently store the image uuid in <nova:root type="image" uuid="993fddc9-8bd4-48a4-b894-c71c2298ddf3"/> | 23:41 |
| Callum027 | Yes it is, so nova:baseImageRef is technically not required. The main reason I have that in there is because from notifications that value is set as image_meta.base_image_ref, and that is what Ceilometer uses to set image_ref in its sample metadata | 23:44 |
| sean-k-mooney | i think i woudl want the xml to look like this https://paste.opendev.org/show/826974/ | 23:44 |
| Callum027 | Ah, I see | 23:45 |
| sean-k-mooney | so i added uuid to flavor | 23:45 |
| sean-k-mooney | and add name and uuid to the image tag | 23:45 |
| sean-k-mooney | put the top level image atribut at the top at the same level as proeprteis adn nested each propety in the properties arry | 23:46 |
| sean-k-mooney | that ust makes the xml a little bit more self consitent | 23:46 |
| Callum027 | That does look good, yeah. Just one more case this needs to cover, though: Instances can be booted from volumes that were originally created from image. In this case there are image_meta details we want, but the UUID is NOT set. As long as Nova, Ceilometer and anything else downstream can handle uuid being "", that should be fine. | 23:47 |
| sean-k-mooney | yep that shoudl be fine | 23:47 |
| sean-k-mooney | we coudl aslo encode if it BFV or not if that was helpfuly | 23:47 |
| sean-k-mooney | but i think haveign empty sting woudl be fine too | 23:48 |
| Callum027 | When implementing it I would probably check both for existence and empty string of the uuid field, yeah | 23:48 |
| Callum027 | And in that case just set base_image_ref on the Ceilometer side to empty string to match the Nova notifications | 23:49 |
| sean-k-mooney | if i was doign thei chagne i woudl also add the flavor extra spec too for my usecase | 23:49 |
| sean-k-mooney | that a bit beyond what you orgnally needed | 23:49 |
| Callum027 | Yep, I can do that | 23:49 |
| sean-k-mooney | but my orgianl motivation was to aide in debugging | 23:50 |
| Callum027 | It's beyond what I needed but it would address another major issue with Ceilometer because it needs to do a Nova API to get that info | 23:50 |
| Callum027 | And adding the image UUID would eliminate that | 23:50 |
| sean-k-mooney | ya so often when im looking at custoemr or upsteam bug reports | 23:50 |
| sean-k-mooney | we are given the xml or a log with an error | 23:50 |
| sean-k-mooney | btu we do not nessiarly have access to a db dump or the image/flavor defintions | 23:51 |
| sean-k-mooney | so we ofthen have to ask for this info | 23:51 |
| sean-k-mooney | just having it in the xml woudl hlep make that less painful | 23:51 |
| Callum027 | Yes it would, exactly | 23:51 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Add new option to enforce multipath volume connections https://review.opendev.org/c/openstack/nova/+/845660 | 23:52 |
| Callum027 | Anything else you can think of at this point in time? I'll update the blueprint and the patch in accordance with what we've discussed this afternoon | 23:53 |
| sean-k-mooney | no that would solve my wishlist items too but dont feel pressrued ot extend the scope if you dont feeel it useful | 23:54 |
| sean-k-mooney | if you do feel like adding that extra info and adjusting the format however i think it could be a very nice little enhancment | 23:55 |
| tkajinam | sean-k-mooney dansmith bauzas, updated https://review.opendev.org/c/openstack/nova/+/845660 . thanks for the review ! | 23:55 |
| Callum027 | Yes, I think there is scope to add the flavour UUID here as well, as it addressed a semi-unrelated but also significant pain point in Ceilometer's compute agent | 23:56 |
| opendevreview | Merged openstack/placement master: Drop SQLALCHEMY_WARN_20 https://review.opendev.org/c/openstack/placement/+/929397 | 23:57 |
| sean-k-mooney | Callum027: back in the dark old days the domain uuid did nto use to be the nova uuid either | 23:57 |
| sean-k-mooney | Callum027: we added that because orgianly celiometer and thinks like colelctd had to lookup the isntance by name which was not alwasy unique | 23:58 |
| sean-k-mooney | so if we can add small things to make that better and avoid more rest calls that win win | 23:58 |
| sean-k-mooney | it removes load for mthe nova api and keeps things local to the agent | 23:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!