| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-10-07 | |||
| 16:16:27 | elodilles | #info stable branches (stable/2025.* and stable/2024.*) seem to be in OK state | |
| 16:16:39 | elodilles | that's all from me, back to you Uggla | |
| 16:17:09 | Uggla | good if it is calm | |
| 16:17:24 | elodilles | yepp :) | |
| 16:17:50 | Uggla | #topic vmwareapi 3rd-party CI efforts Highlights | |
| 16:17:58 | fwiesel | No updates from my side. | |
| 16:18:08 | Uggla | fwiesel, thx | |
| 16:18:36 | Uggla | gibi seems not available. | |
| 16:19:07 | gibi | sorry | |
| 16:19:10 | gibi | no news from me | |
| 16:19:37 | Uggla | gibi, that's perfectly ok. | |
| 16:19:45 | gibi | (busy with other bugfixes) | |
| 16:20:15 | Uggla | gibi, I know. Important fixes. | |
| 16:20:36 | Uggla | #topic Open discussion | |
| 16:20:51 | Uggla | (Uggla) Pool for the new schedule of upstream meeting: https://framadate.org/ao12zK6wR3K3nfbF | |
| 16:20:57 | Uggla | #linkAnnonce : https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/H5PBFZJ4X3TSGSC4YF6E4WTV43CBOVS6/ | |
| 16:21:29 | Uggla | please vote ^ | |
| 16:22:28 | bauzas | I saw it but I need to calculate with all the existing meetings, it will take time before replying :( | |
| 16:22:58 | Uggla | By the way as mentionned in the mail, we will have to adjust it again with the daylight change. | |
| 16:23:34 | elodilles | Uggla: which one, the US or the EU daylight change? | |
| 16:24:03 | elodilles | (or other, that i'm not aware of...) | |
| 16:25:05 | gibi | hm the voting options are in UTC that is not observing daylight saving | |
| 16:25:06 | Uggla | elodilles, I think the EU. Otherwise most of us will have a conflict. | |
| 16:26:07 | elodilles | (end of DST in EU: Oct 26, 2025; end of DST in US: Nov 2, 2025; if I'm not mistaken) | |
| 16:26:15 | elodilles | Uggla: ACK | |
| 16:27:12 | Uggla | elodilles, that also depends the day we will choose. | |
| 16:27:14 | gibi | but if we want to observe daylight saving then the option cannot be UTC as UTC is not affected by daylight saving | |
| 16:27:54 | Uggla | gibi, the tool upstream only accept UTC. | |
| 16:28:22 | elodilles | (and that is more 'readable' for every participants) | |
| 16:28:44 | elodilles | (at least that is a 'common' timezone everyone understands) | |
| 16:28:46 | gibi | which is fine by me. But you are talking about changing during dayligh saving and that does not make sense to me as UTC is not affected | |
| 16:30:01 | gibi | e.g. if I vote 16:00 UTC, then it is always 16:00 UTC regardless of where am I on earth and what part of the year we are | |
| 16:30:26 | gibi | do you suggest we will update the 16:00 UTC to some other time when we move to daylight saving? | |
| 16:30:41 | Uggla | gibi, after the daylight our meeting which is usually at 18h00 CET, will move to 17h00 CET and will conflict with one internal. | |
| 16:30:55 | Uggla | "do you suggest we will update the 16:00 UTC to some other time when we move to daylight saving?" yes absolutelly | |
| 16:31:17 | gibi | why? :) | |
| 16:31:42 | Uggla | We will probably have to move from 16:00 UTC to 17:00 UTC. | |
| 16:32:02 | gibi | do you want to keep the timing constant in EU? | |
| 16:32:20 | gibi | that will create 4 changes of time in US | |
| 16:32:33 | gibi | probably not something the US folks will like | |
| 16:32:49 | gibi | if we stick to UTC then both EU and US has 2 changes per year to adapt to | |
| 16:33:35 | Uggla | s/want/wants/ | |
| 16:34:51 | Uggla | But having internal ones in UTC would help. | |
| 16:34:56 | bauzas | honestly, there is no solution here, let's continue with UTC and just signal when we have conflicts after DST | |
| 16:35:07 | gibi | I think sticking to UTC is the least confusing for the community. Moving twice a year to keep the EU time constant is an optimization for EU but a complication for U | |
| 16:35:31 | gibi | I have to drop now but I will read back... | |
| 16:35:34 | bauzas | that's why it takes time to look at the framedate one given I need to look at both of the times | |
| 16:36:19 | Uggla | bauzas, yep | |
| 16:36:51 | Uggla | Anyway, something else to discuss ? | |
| 16:37:37 | kgube | I just wanted to ask, is there a cross-project session planned with Cinder at the PTG? | |
| 16:38:06 | Uggla | kgube, I have not discussed with cinder yep, but probably yes. | |
| 16:38:23 | kgube | alright, thanks! | |
| 16:39:06 | Uggla | If you want to have a cross discussion with cinder, please write that in our doc, and I'll arrange with Cinder folks to find a timeslot. | |
| 16:39:47 | kgube | The NetApp/NFS online resize topic might fit well there, I have added a comment | |
| 16:40:14 | Uggla | ok, please also add your name around? | |
| 16:40:42 | Uggla | Anything else ? | |
| 16:42:31 | bauzas | - | |
| 16:43:23 | Uggla | ok so thanks for joining this meeting, closing now. | |
| 16:43:34 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-10-07-16.00.log.html | |
| 16:43:34 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-10-07-16.00.txt | |
| 16:43:34 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-10-07-16.00.html | |
| 16:43:34 | opendevmeet | Meeting ended Tue Oct 7 16:43:34 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:43:34 | Uggla | #endmeeting | |
| 16:43:41 | elodilles | thanks o/ | |
| 16:44:06 | fwiesel | Thanks! | |
| 16:44:08 | Uggla | elodilles, you are welcome | |
| 16:46:09 | bauzas | Uggla: thanks | |
| 16:54:18 | bauzas | dansmith: found why we didn't found the fill_metadata issue with the unittests | |
| 16:54:26 | dansmith | melwitt: question/sanity-check for you | |
| 16:54:34 | dansmith | melwitt: in https://review.opendev.org/c/openstack/nova/+/942502 | |
| 16:54:41 | bauzas | but I wonder how to fix the coverage | |
| 16:55:23 | dansmith | bauzas: I still haven't heard a problem in the code I agree with, but .. go on :) | |
| 16:55:23 | bauzas | anyway, just looking at the time, I need to leave now :( | |
| 16:55:28 | dansmith | ack | |
| 16:55:33 | bauzas | very quickly | |
| 16:55:41 | bauzas | updated[inst.uuid]) | |
| 16:55:41 | bauzas | inst.system_metadata = utils.instance_sys_meta( | |
| 16:55:47 | melwitt | dansmith: looking | |
| 16:55:51 | bauzas | that's what I fixed | |
| 16:56:04 | bauzas | because we were having a dict of dict | |
| 16:56:23 | dansmith | bauzas: oh the dict thing, right, but I also want to know why it passed our QE... | |
| 16:56:33 | dansmith | bauzas: anyway, put up a full patch and I'll look | |
| 16:57:01 | bauzas | but given the instances you createed in https://github.com/openstack/nova/commit/420050cf33dd58bc6b608540fc8f32b2f65ef274 don't have any metadata recorded in DB, then it always returns an empty dict | |
| 16:57:28 | bauzas | dansmith: ack, will upload a patch and try to write some comment + some pastebin | |
| 16:57:43 | bauzas | I need to leave for tai-chi but hopefully be back around 7pm UTC | |
| 16:59:13 | bauzas | long story short, I need to find a way to persist some metadata for the instances you create in test_fill_metadata() so that when calling db.instances_fill_metadata() we get those values for adding them into the object metadata itself | |
| 16:59:42 | bauzas | my brain is fried and I have to run errand | |
| 17:00:55 | dansmith | okay | |
| 17:01:46 | dansmith | melwitt: I think you're going to say it's expected behavior and it looks like the resize patch has a lot of conversion logic.. | |
| 17:02:28 | dansmith | I'm not sure if I think it's problematic behavior, but it's very much not what I expected | |
| 17:02:58 | melwitt | dansmith: yes I am typing that. I think the main issue is that in the 'user' patch the resize is not looking at image_hw_ in sysmeta but it should be (ignoring all of these patches ...) so I'm currently confused about that | |
| 17:03:07 | dansmith | because I don't know how to reconcile when the flavor and image disagree (especially in this case where I haven't set anything on my image) | |
| 17:04:02 | dansmith | melwitt: if it's not looking at image_hw_tpm_security then I don't know why it let me schedule to a user host when the flavor requests a host host | |
| 17:04:26 | melwitt | dansmith: yeah. that's what I was chatting with sean about last week is, is this going to be a problem that we have overloaded the image_hw_tpm_secret_security sysmeta key when it did not necessarily come from any image | |
| 17:05:38 | melwitt | dansmith: it's because there is no trait filtering logic yet at that point in the series. it knows nothing about 'host' at this point so it's treating it as if it doesn't exist. it is still 'user' despite the fact that it lets you set the flavor as 'host' | |
| 17:06:23 | dansmith | melwitt: eh? isn't this the trait filtering? https://review.opendev.org/c/openstack/nova/+/942502/19/nova/scheduler/request_filter.py | |
| 17:06:26 | melwitt | dansmith: so I guess maybe what I need to do is at least make it know about the "will-be-valid" values early on to reject them until support is introduced | |
| 17:06:37 | dansmith | oh, | |
| 17:06:47 | dansmith | you mean because it lets any security it doesn't know about through | |
| 17:06:52 | melwitt | yes | |