| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-07-01 | |||
| 16:39:47 | cardoe | So when we'd go to clean up, anything that wasn't at the current version could get nuked. | |
| 16:39:59 | sean-k-mooney | fwiesel: so testing that in tempest would be hard, but it would be more doable in the functional suite | |
| 16:40:03 | cardoe | But there's all kinds of dangling references to storage and what not that really are a pain to fix | |
| 16:40:36 | gibi | yepp use functional test for sure | |
| 16:40:51 | fwiesel | Okay, I'll take that with me. Thanks. | |
| 16:40:52 | gibi | we have a limited evact test somewhere after tempest | |
| 16:40:57 | sean-k-mooney | cardoe: so we dont need montic object version in general becasue we assocate the instance with the comptue service that is currently manging it | |
| 16:40:58 | gibi | in a palybook | |
| 16:41:11 | sean-k-mooney | in the post test hook in nova-next | |
| 16:41:16 | cardoe | For us we implemented this more as monitoring that an unexpected object was on a host. | |
| 16:41:17 | sean-k-mooney | and i think the cepch job? | |
| 16:42:03 | sean-k-mooney | cardoe: ya so that kind of approch is not very comaptible with the nova desing although we do have some per host perodic that are intened ot clean up these types of issues | |
| 16:42:08 | cardoe | sean-k-mooney: when you perform a live migrate and the dest goes down at the very end during the resume | |
| 16:42:09 | sean-k-mooney | esplcially on compute agent start up | |
| 16:42:53 | sean-k-mooney | cardoe: if the vm dies before resume libvirt will abort the migraiot | |
| 16:43:01 | sean-k-mooney | if we got to post live migrate | |
| 16:43:21 | sean-k-mooney | its too late to abort but we will update the instance hsot to point to the dest | |
| 16:43:28 | gibi | this is the evac testing in devstack https://github.com/openstack/nova/blob/master/roles/run-evacuate-hook/tasks/main.yaml | |
| 16:43:58 | Uggla | guys is it ok to move to the second point ? | |
| 16:44:05 | gibi | OK for me | |
| 16:44:08 | cardoe | I'm just saying it wasn't a simple problem when I was working in the VM world because hardware dies at the worst possible times and nova can be in many different code calls when that happens. | |
| 16:44:10 | sean-k-mooney | yep lets move on for now. | |
| 16:44:24 | Uggla | #topic (jonnyb) Blueprint for new compute created weigher (https://blueprints.launchpad.net/nova/+spec/node-uptime-weigher) | |
| 16:44:47 | Uggla | jonnyb wants to discuss about this weigher | |
| 16:45:01 | Uggla | jonnyb please go ahead. | |
| 16:45:13 | jonnyb | so I propose a scheduler weigher based on creation date of the compute service | |
| 16:45:41 | jonnyb | the initial idea was to use uptime but this is too dependend on the hypervisor and its driver | |
| 16:46:11 | jonnyb | for us the creation is good enough and we use it since we migrate and deploy a lot of servers | |
| 16:46:13 | gibi | do you have the service creation time as part of the HostState the weigher running on? | |
| 16:46:29 | sean-k-mooney | i belive we do | |
| 16:46:36 | dansmith | that surprises me | |
| 16:46:53 | sean-k-mooney | we have it form the compute node object i belive | |
| 16:47:01 | dansmith | sure, but in hoststate? | |
| 16:47:38 | sean-k-mooney | so this is the poc https://review.opendev.org/c/openstack/nova/+/947503/9/nova/scheduler/weights/compute_created.py | |
| 16:48:27 | dansmith | we have an object, but I didn't think it was queried from the db and thus not complete, but maybe that's not right | |
| 16:49:08 | sean-k-mooney | so yes https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L176 | |
| 16:49:26 | gibi | based on the poc we have HostState.service.created_at as created_at does not expect to change it is fair to assume it is up to date | |
| 16:49:26 | sean-k-mooney | you could be correct about it being a partial object | |
| 16:49:45 | gibi | isn't expected to change | |
| 16:50:34 | sean-k-mooney | so it looks like this is only populated via update its not populated iva __init__ | |
| 16:51:02 | sean-k-mooney | so im not sure if its there if you disatble the track_isntace_state notifications stuff | |
| 16:51:17 | dansmith | okay we are doing a scatter to gather nodes and hosts from cells | |
| 16:51:18 | sean-k-mooney | we woudl have to confirm that its always present in both confiugrations | |
| 16:51:30 | dansmith | I was thinking we did an optimized construction from a list there | |
| 16:51:44 | dansmith | sean-k-mooney: yeah, good point | |
| 16:52:11 | sean-k-mooney | i think that config only affect the instnace object and how those are populated | |
| 16:52:16 | dansmith | because this could also be triggering massive lazy loads, which would be bad | |
| 16:52:19 | sean-k-mooney | but assuming we have that alwasy | |
| 16:52:43 | sean-k-mooney | i think it would be ok to use it in the weigher provide ya we are not lazy loading this | |
| 16:53:04 | dansmith | we need to make sure this is run in CI at least once so we can examine logs for lazy loads | |
| 16:56:32 | sean-k-mooney | ya we can turn this on in one fo the jobs | |
| 16:57:08 | sean-k-mooney | it wont really have much of an effect with only 1-2 nodes | |
| 16:57:10 | dansmith | we don't have to permanently, but just a DNM on top of this to get a run and make sure we don't see "lazy loading service.created_at" :) | |
| 16:58:10 | sean-k-mooney | we are wrappign the sercie in a readonly dict class that i have not really seen before. i would assume that shoudl also block lazyloading? | |
| 16:58:24 | sean-k-mooney | goign back on topic | |
| 16:58:34 | sean-k-mooney | are we ok with appvoing this as a specless blueprint | |
| 16:58:38 | sean-k-mooney | and continuing to review | |
| 16:59:16 | dansmith | idk | |
| 16:59:53 | Uggla | :+1 for me it looks an interesting weigher. | |
| 17:00:20 | Uggla | gibi, ok for you ? | |
| 17:00:24 | gibi | I'm fine | |
| 17:00:46 | sean-k-mooney | i dont nessiarly have an objection just note that if there are lazy loadign issues they will need to be resolved ebfore we can merge it | |
| 17:00:56 | dansmith | same | |
| 17:00:58 | sean-k-mooney | so it might not be ready before FF | |
| 17:01:17 | sean-k-mooney | but im ok to move to the review and take a look a ci logs ectra | |
| 17:01:30 | Uggla | jonnyb is that ok for you ? | |
| 17:01:35 | jonnyb | thats fine with me, i wasnt aware that lazy loading could be an issue. but good point | |
| 17:02:04 | sean-k-mooney | you defaulted to 1.0 so in theroy its enabled by default | |
| 17:02:15 | sean-k-mooney | so we should b eable to look at any of the current ci logs | |
| 17:02:28 | Uggla | #topic (gibi) Workaround for cpython3.13 GC bug needs review https://review.opendev.org/c/openstack/nova/+/952966 | |
| 17:02:28 | Uggla | ok last topic: | |
| 17:02:36 | dansmith | oh, definitely seems like it should be disabled by default | |
| 17:02:53 | dansmith | that's merged? | |
| 17:03:05 | sean-k-mooney | well we can defintly change that. in the review and ya the gc thing is merged | |
| 17:03:26 | gibi | yepp it is merged | |
| 17:03:29 | Uggla | dansmith yes it seems | |
| 17:03:48 | gibi | I proposed the backport to Epoxy as I know debian want it there | |
| 17:04:23 | gibi | (the cpython bug fixing effort is progressing in the background) | |
| 17:05:14 | gibi | so other than the backport there is nothing else left here | |
| 17:05:18 | gibi | we can move on | |
| 17:05:41 | sean-k-mooney | jonnyb: so without diging deeply https://zuul.opendev.org/t/openstack/build/8a9b0a0404034a79a95621b18e16534b/log/controller/logs/screen-n-sch.txt#1017 you schduler was enabeld and i dont see lazy loadign but we need to look at that properly after the meeting | |
| 17:05:44 | Uggla | ok cardoe, wants to discuss about a patch | |
| 17:06:03 | Uggla | cardoe please go ahead, and then we will close. | |
| 17:06:07 | cardoe | https://review.opendev.org/c/openstack/nova-specs/+/471815 | |
| 17:06:36 | cardoe | It is a proposed spec change to add trunk ports with their vlan tags to the network_data.json | |
| 17:06:47 | sean-k-mooney | ya im +2 on that gibi is +1 because they wont have review bandwith i belvie | |
| 17:07:04 | gibi | I'm +2-1=+1 signalling review bandwidth yes | |
| 17:07:16 | cardoe | It's something written originally by someone not involved in the effort currently. | |
| 17:07:23 | cardoe | But neutron supports defining ports like that. | |
| 17:07:55 | cardoe | There have been a few patches floating around from different operators that are using that functionality as a downstream patch. | |
| 17:07:56 | dansmith | sean-k-mooney: jonnyb: agree, I see the weigher being weighed and no lazy loads in that log, so seems fine | |
| 17:08:06 | gibi | having +1 from rubasov (Bence) is a good sign, he was involved in the original work of trunk | |
| 17:08:15 | cardoe | I've been working to consolidate the downstream operators around a single implementation and wanting to get it upstreamed. | |
| 17:08:20 | sean-k-mooney | yep | |
| 17:08:48 | cardoe | We've got temptest tests written and an implementation. | |
| 17:08:52 | sean-k-mooney | there is code for noav and tempest test too | |
| 17:09:04 | sean-k-mooney | ya https://review.opendev.org/q/topic:%22bp/expose-vlan-trunking%22 | |
| 17:09:20 | sean-k-mooney | this is useful for both vms adn for ironic | |
| 17:09:24 | cardoe | This is just part of my TC work to try and get downstream operators to push back to the community. | |
| 17:10:29 | sean-k-mooney | so the requwst is bascily for another core to sponsor/review this before spec freeze on thruday | |