Earlier  
Posted Nick Remark
#openstack-nova - 2025-02-27
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
23:25:35 Callum027 published to Gnocchi.
23:25:56 sean-k-mooney well notificatoin are really ment to be fire and forget
23:26:11 sean-k-mooney they are not inteded as a reliable message deliveray mechanium
23:26:21 sean-k-mooney so ya i can see why that would nto be ideal for billing
23:26:30 Callum027 Yes, and for billing we want to accurately know the state of the resource at the time it was polled
23:26:37 Callum027 Otherwise we're not billing correctly
23:27:50 sean-k-mooney ya makes sesne. so next steps, RC1 is planed for 2 weeks time
23:28:22 sean-k-mooney the week after that will be the first irc meetign of the 2025.2 development cycle
23:28:47 sean-k-mooney that would be yoru first real opertunity to ask for the spec to be approved
23:28:58 sean-k-mooney *bluepirnt to be approved
23:29:37 Callum027 Alright, sounds good, so the meeting for the week of 17-23 March?
23:30:25 sean-k-mooney yes im not sure if this time https://meetings.opendev.org/#Nova_Team_Meeting suits you
23:30:40 sean-k-mooney if not you can ask for the blueprint to be approved on the mailing list
23:31:13 Callum027 Tuesday 1600 UTC is Wednesday 0700 NZDT so I should be okay for that
23:31:38 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:47 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:32:19 sean-k-mooney basifclly there is an open dicusstion section here https://wiki.openstack.org/wiki/Meetings/Nova

Earlier   Later