| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-02-27 | |||
| 18:35:32 | sean-k-mooney | not tuesday | |
| 18:36:12 | sean-k-mooney | which is why i was hopign we could proceed with https://review.opendev.org/c/openstack/nova/+/938604 | |
| 18:36:20 | gmann | sean-k-mooney ok its today right not next thursday? | |
| 18:36:46 | sean-k-mooney | ill check again | |
| 18:36:50 | sean-k-mooney | maybe im off by a week | |
| 18:36:58 | gmann | days are confusing there, having date will be more clear | |
| 18:37:05 | sean-k-mooney | https://releases.openstack.org/epoxy/schedule.html#epoxy-3-milestone | |
| 18:37:12 | sean-k-mooney | February 27, 2025 i | |
| 18:37:15 | sean-k-mooney | so today | |
| 18:37:16 | gmann | I asked bauzas just to be more clear | |
| 18:37:23 | 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:59 | sean-k-mooney | gmann: nova observes the unifed feature freeze with is milesotone 3 which is today February 27, 2025 | |
| 18:38:15 | gmann | sean-k-mooney: ohk, great then we are on perfect time for 938604 | |
| 18:38:52 | sean-k-mooney | ya so we normally allow things that are +w to merge up until the next irc meeting | |
| 18:39:00 | Uggla | Hi stephenfin, I'd like to. But I'm unsure I'll find time to do it. :( | |
| 18:39:12 | sean-k-mooney | so if its approved by close of buisness PST | |
| 18:39:19 | sean-k-mooney | then we consider it in for FF | |
| 18:39:32 | sean-k-mooney | even if it only merges at the weekend | |
| 18:39:46 | gmann | yeah, just +W on that | |
| 18:39:53 | stephenfin | Guess it's for next cycle so. You'll just have to remember to backport it if you need it downstream | |
| 18:42:48 | Uggla | stephenfin, unfortunately yes. But my current prio is on VFIO PCI live migration. | |
| 18:43:58 | 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:44:24 | gmann | I *fixed* one thing | |
| 18:45:41 | sean-k-mooney | i saw the first one this morning but didnt review it yet | |
| 18:46:02 | gmann | k] | |
| 18:46:02 | 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:08 | gmann | cool | |
| 18:46:13 | sean-k-mooney | i think 2.96 was last cycle | |
| 18:47:06 | sean-k-mooney | oh it was carical | |
| 18:47:11 | sean-k-mooney | so 2024.1 | |
| 18:47:40 | 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:48:01 | gmann | will do that once master change is merge | |
| 18:48:59 | 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:50:27 | gmann | thanks | |
| 19:44:00 | 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:00 | 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:01 | 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:53:13 | 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:31 | sean-k-mooney | ill try an take a look at this again tomorrow | |
| 19:53:59 | sean-k-mooney | but since we do not have tempest testing for this the funcitonal test weill need to be pretty exaustive | |
| 19:54:47 | sean-k-mooney | and i dont want ot merge any of the migration series until we are +2 on all the patches | |
| 20:23:54 | opendevreview | Merged openstack/nova master: Drop environment for Python 3.8 https://review.opendev.org/c/openstack/nova/+/939027 | |
| 20:44:30 | 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:31 | Callum027 | the patch itself if a core reviewer has free time to do so. Thanks! | |
| 22:53:29 | 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:51 | sean-k-mooney | Callum027: i have some idea of what i would like to include if we extend the metadta futher | |
| 22:54:25 | sean-k-mooney | notable we currenly store some metadata about the image and falvor but we dont express that consitently in the xml | |
| 22:55:13 | 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:31 | sean-k-mooney | provdrive the extra specs and properties for both | |
| 22:56:42 | Callum027 | Hi sean-k-mooney, interesting, got any links to what you proposed earlier? | |
| 22:57:35 | 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:58:18 | 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:20 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/923910/5/nova/virt/driver.py#49 | |
| 22:58:27 | sean-k-mooney | and ^ were the calsess we ended up with | |
| 22:59:09 | sean-k-mooney | what i didnt end of pocign was basiclly the changes to print all fo the files in the xml | |
| 22:59:38 | sean-k-mooney | so for image you see it has id name and propereis | |
| 23:00:12 | 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:33 | sean-k-mooney | so some of those files were doped in the version we merged because ironic didnt need them | |
| 23:03: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:19 | sean-k-mooney | so either i didnt commit it or i did but didnt push it anywaher | |
| 23:04:30 | sean-k-mooney | Callum027: lookign at your patch | |
| 23:04:43 | sean-k-mooney | you seam to be extendign the ground work we created 6 months ago | |
| 23:05:25 | 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:06:02 | sean-k-mooney | to me the image prorpees were the most valueabel rather then min_(ram/disk) or the format | |
| 23:06:23 | opendevreview | Merged openstack/placement master: doc: Use dnf instead of yum https://review.opendev.org/c/openstack/placement/+/938499 | |
| 23:06:27 | opendevreview | Merged openstack/nova master: doc: Use dnf instead of yum https://review.opendev.org/c/openstack/nova/+/938496 | |
| 23:07:05 | 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:10 | sean-k-mooney | Callum027: whiel at the saem time your not including the name or id | |
| 23:07:38 | Callum027 | Actually, I don't think min_ram etc are actually used by Ceilometer out of the box but why not I thought | |
| 23:08:11 | 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:24 | sean-k-mooney | is i knwo some of the nova core are concerned with not makign the metadta too log | |
| 23:08:58 | 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:09:08 | sean-k-mooney | where having this info would have made it seconds | |
| 23:09:25 | sean-k-mooney | so i think ther is value in provide at least some of it in the xml | |
| 23:11:24 | 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:44 | sean-k-mooney | Callum027: are you famialr with our process for proposing new features? | |
| 23:11:53 | Callum027 | I'm afraid not no | |
| 23:12:35 | 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:13:01 | sean-k-mooney | today is actully Feature Implemation Freeze for the 2025.1 release | |
| 23:13:38 | 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:14:19 | 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:42 | sean-k-mooney | or if we think it need more detailed deicsion we may ask for a spec docuemnt | |
| 23:15:33 | sean-k-mooney | in this case i think it could be a specless blueprint but we will have to see how other feel | |
| 23:16:04 | sean-k-mooney | Callum027: also as we are at the end of one release syscycle and will be starting another shortly | |
| 23:16:27 | sean-k-mooney | we will have a virtual comunity event call the PTG (project teams gattering) april 7-11th | |
| 23:16:59 | 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:17:40 | sean-k-mooney | Callum027: ah i just check you have contibuted to ceilometer and adjusat before | |
| 23:17:56 | sean-k-mooney | Callum027: so you are proably familar with the general flow. | |
| 23:19:29 | 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:36 | Callum027 | So this explanation was very helpful, thank you | |
| 23:19:57 | 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:21:13 | sean-k-mooney | Callum027: may i ask what is the end goal that this enables | |
| 23:21:19 | 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:19 | Callum027 | can provide this information as well. | |
| 23:21:38 | sean-k-mooney | ah ok | |
| 23:22:00 | sean-k-mooney | part of the reason i ask is i ahve recnetly been workign a bit on watcher | |
| 23:22:34 | sean-k-mooney | we ahve been addign the ablity to pull data form prometeous (and we have celomiter metrics feeding into promethous) | |
| 23:22:56 | sean-k-mooney | Callum027: so i was trying to decied if this would be useful in that context | |
| 23:23:42 | 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:25:35 | 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 | |