| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-02-27 | |||
| 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 | can provide this information as well. | |
| 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: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 | published to Gnocchi. | |
| 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: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 | |
| 23:32:52 | 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:33:14 | 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:54 | 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:34:42 | 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:47 | Callum027 | agenda* | |
| 23:35:15 | Callum027 | I should be able to be there at the meeting time as well | |
| 23:35:19 | 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:41 | sean-k-mooney | so you coudl see but we might say lets wait until we are doen with 2025.1 first | |
| 23:36:24 | Callum027 | Sounds good! | |
| 23:37:49 | sean-k-mooney | just looking at this in the ci | |
| 23:37:51 | sean-k-mooney | https://zuul.opendev.org/t/openstack/build/aeae5e9ef4c042fb89555623e3be9466/log/controller/logs/screen-n-cpu.txt#9620 | |
| 23:38:30 | 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:41:06 | sean-k-mooney | that the relevent part https://paste.opendev.org/show/bbHRV4uzP2yZr8j7yPEW/ | |
| 23:41:19 | sean-k-mooney | if i was to update it i would modify it slightly | |
| 23:41:59 | sean-k-mooney | we currently store the image uuid in <nova:root type="image" uuid="993fddc9-8bd4-48a4-b894-c71c2298ddf3"/> | |
| 23:44:42 | sean-k-mooney | i think i woudl want the xml to look like this https://paste.opendev.org/show/826974/ | |
| 23:44:42 | 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:45:03 | Callum027 | Ah, I see | |
| 23:45:17 | sean-k-mooney | so i added uuid to flavor | |
| 23:45:26 | sean-k-mooney | and add name and uuid to the image tag | |
| 23:46:00 | 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:43 | sean-k-mooney | that ust makes the xml a little bit more self consitent | |
| 23:47:05 | 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:37 | sean-k-mooney | yep that shoudl be fine | |
| 23:47:51 | sean-k-mooney | we coudl aslo encode if it BFV or not if that was helpfuly | |
| 23:48:13 | sean-k-mooney | but i think haveign empty sting woudl be fine too | |
| 23:48:43 | Callum027 | When implementing it I would probably check both for existence and empty string of the uuid field, yeah | |
| 23:49:04 | Callum027 | And in that case just set base_image_ref on the Ceilometer side to empty string to match the Nova notifications | |
| 23:49:37 | sean-k-mooney | if i was doign thei chagne i woudl also add the flavor extra spec too for my usecase | |
| 23:49:49 | sean-k-mooney | that a bit beyond what you orgnally needed | |
| 23:49:50 | Callum027 | Yep, I can do that | |
| 23:50:06 | sean-k-mooney | but my orgianl motivation was to aide in debugging | |
| 23:50:10 | 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:19 | Callum027 | And adding the image UUID would eliminate that | |
| 23:50:45 | sean-k-mooney | ya so often when im looking at custoemr or upsteam bug reports | |
| 23:50:59 | sean-k-mooney | we are given the xml or a log with an error | |
| 23:51:16 | sean-k-mooney | btu we do not nessiarly have access to a db dump or the image/flavor defintions | |
| 23:51:26 | sean-k-mooney | so we ofthen have to ask for this info | |
| 23:51:44 | sean-k-mooney | just having it in the xml woudl hlep make that less painful | |
| 23:51:57 | Callum027 | Yes it would, exactly | |
| 23:52:49 | 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:53:14 | 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:54:19 | 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:55:33 | 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:38 | tkajinam | sean-k-mooney dansmith bauzas, updated https://review.opendev.org/c/openstack/nova/+/845660 . thanks for the review ! | |
| 23:56:21 | 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:57:05 | opendevreview | Merged openstack/placement master: Drop SQLALCHEMY_WARN_20 https://review.opendev.org/c/openstack/placement/+/929397 | |
| 23:57:41 | sean-k-mooney | Callum027: back in the dark old days the domain uuid did nto use to be the nova uuid either | |
| 23:58:22 | 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:39 | sean-k-mooney | so if we can add small things to make that better and avoid more rest calls that win win | |
| 23:59:10 | sean-k-mooney | it removes load for mthe nova api and keeps things local to the agent | |
| #openstack-nova - 2025-02-28 | |||
| 00:00:25 | sean-k-mooney | tkajinam: readded my +2 | |
| 00:01:03 | sean-k-mooney | tkajinam: i think we can pretent thid mergd today and if bauzas and dansmith agree merge it tomorrow | |
| 00:01:19 | Callum027 | Yep, exactly, I'm happy to hear that. Looks like Ceilometer also does an API lookup to get `server.metadata` as well, I think I'll add that to the blueprint as well and we can call this a "add everything missing that Ceilometer needs" | |
| 00:01:51 | sean-k-mooney | so that a littel diffent | |
| 00:02:19 | sean-k-mooney | the peroblem with server.metadat is tha tcan change at any time since its the metadta proved to the end user within the metadta api | |
| 00:02:38 | sean-k-mooney | Callum027: that not exactly private data but it shoudl not really be in the xml | |
| 00:02:49 | Callum027 | Oh, that's too bad then | |
| 00:03:12 | Callum027 | In that case that might be a topic to discuss on the Ceilometer side on how to handle that in the future | |
| 00:03:26 | sean-k-mooney | we coudl perhaps dicusss that as a follow up but i susptec that woudl get pushback on privacy grounds | |
| 00:04:34 | Callum027 | Fair enough. For my use case it's not required, there might be scope to simply disable fetching that inside Ceilometer if the administrator doesn't require it, especially if it could cause privacy issues by exposing it. | |
| 00:04:39 | sean-k-mooney | Callum027: ill put it to you this way. while you would never pass a password via server metadata you might pass the lookup keey to pull applciation config form vault via metadata | |