Earlier  
Posted Nick Remark
#openstack-nova - 2025-03-11
14:59:46 opendevreview sean mooney proposed openstack/nova master: only show standard image properties in server show. https://review.opendev.org/c/openstack/nova/+/942413
14:59:46 opendevreview sean mooney proposed openstack/nova master: [tests] add priting of sample and templete paths https://review.opendev.org/c/openstack/nova/+/944054
14:59:58 sean-k-mooney dansmith: ^ i think thats what you wanted
15:05:19 opendevreview Dan Smith proposed openstack/nova master: [tests] Add printing of sample and template paths https://review.opendev.org/c/openstack/nova/+/944054
15:05:55 dansmith sean-k-mooney: got 'em thanks
15:28:41 dansmith bauzas: thanks, I need to quickly tweak that work item title if you can re-apply your +2 after I do, that would be appreciate
15:28:42 dansmith d
15:28:59 bauzas dansmith: sure
15:29:52 opendevreview Dan Smith proposed openstack/nova-specs master: Add one-time-use-devices spec https://review.opendev.org/c/openstack/nova-specs/+/943486
15:30:05 dansmith that ^ just makes the work item reflect the discussion and the pre-review on the PoC
15:32:02 sean-k-mooney dansmith: just an fyi i have been putting off doing some ramp on horizon stuff for like 2 weeks so im tryign to spend the rest of the week doing that. ill loop back to the spec firday or early next week
15:32:48 dansmith sean-k-mooney: no worries, we've made a lot of quick progress and I have lots of smaller items to do (like all the test coverage and startup checks) so I'm good for a while for sure
15:33:20 dansmith surely appreciate sean-k-mooney gibi and bauzas helping sanity check everything early so I can work on implementing the things
15:33:54 bauzas dansmith: I'll try to do code review
16:02:21 bauzas #startmeeting nova
16:02:21 opendevmeet Meeting started Tue Mar 11 16:02:21 2025 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:21 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:21 opendevmeet The meeting name has been set to 'nova'
16:03:22 elodilles o/
16:03:22 bauzas #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
16:03:28 dansmith o/
16:05:58 bauzas I guess we can start
16:06:22 gibi *late
16:07:34 bauzas #topic Bugs (stuck/critical)
16:07:41 bauzas #info No Critical bug
16:07:52 bauzas #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:08:01 bauzas anything to discuss about bugs ?
16:10:47 bauzas looks not
16:10:57 bauzas #topic Gate status
16:12:26 bauzas #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:12:35 bauzas #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status
16:13:34 bauzas all periodics are green
16:13:41 bauzas #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:13:48 bauzas #info Please try to provide meaningful comment when you recheck
16:14:24 bauzas anything about bugs ?
16:17:32 Uggla o/
16:17:47 bauzas #topic Release Planning
16:17:54 bauzas #link https://releases.openstack.org/epoxy/schedule.html
16:18:01 bauzas #info Nova deadlines are set in the above schedule
16:18:12 bauzas #link https://etherpad.opendev.org/p/nova-epoxy-rc-potential
16:18:45 elodilles fyi the RC1 patches are already proposed:
16:18:49 elodilles https://review.opendev.org/c/openstack/releases/+/943941
16:18:55 elodilles and
16:18:57 elodilles https://review.opendev.org/c/openstack/releases/+/943947
16:20:11 elodilles (please add a -1 if something is in the queue to merge o:))
16:20:20 bauzas nova-cores, please look at this etherpad, we have a number of patches to merge before we can propose RC1
16:20:24 bauzas elodilles: will do
16:20:26 bauzas and saw those
16:20:31 elodilles thanks o/
16:23:51 bauzas as a reminder, there is a section in the etherpad for adding bugfixes worth to be delivered
16:23:52 dansmith even without the upcoming baton change, probably best to let someone else run the meeting if you have a conflict
16:24:09 bauzas yeah it just went over for 24 mins :(
16:24:39 bauzas anyway, moving on
16:24:54 bauzas you'll see myself speaking in the channel asking cores to review thinfs
16:25:10 bauzas #topic PTG planning
16:25:28 bauzas #info Next PTG will be held on Apr 7-11
16:25:34 bauzas #link https://etherpad.opendev.org/p/nova-2025.2-ptg
16:25:39 bauzas and that's it
16:25:45 bauzas #topic Stable Branches
16:25:49 bauzas elodilles: please
16:25:54 elodilles yepp
16:26:01 elodilles nothing special to report:
16:26:10 elodilles #info stable gates seem to be healthy
16:26:15 elodilles #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:26:25 bauzas cool
16:26:32 elodilles (and we have some stable/2025.1 already)
16:26:32 bauzas #topic vmwareapi 3rd-party CI efforts Highlights
16:26:46 bauzas fwiesel seems not to be present
16:26:49 bauzas moving on then
16:26:56 bauzas #topic Open discussion
16:27:03 bauzas nothing in the agenda
16:27:07 bauzas anything anyone ?
16:30:06 opendevreview mitya-eremeev-2 proposed openstack/nova master: Add more thorough handling of evacuated instances https://review.opendev.org/c/openstack/nova/+/944058
16:30:44 bauzas looks we can close the meeting
16:30:46 bauzas thanks all
16:30:48 bauzas #endmeeting
16:30:48 opendevmeet Meeting ended Tue Mar 11 16:30:48 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:30:48 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-03-11-16.02.html
16:30:48 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-03-11-16.02.txt
16:30:48 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-03-11-16.02.log.html
16:31:12 dansmith bauzas: ack on the previous going over, sorry I just assumed you meant you intended to be superman and run two meetings at once :P
16:31:13 elodilles thanks o/
16:31:41 bauzas dansmith: well, I really have no choices
16:31:59 bauzas hence myself leaving the hot seat, or I was about to burn
16:38:26 ratailor melwitt, could you please review https://review.opendev.org/c/openstack/nova/+/873901 and provide your feedback ?
16:38:59 ratailor gibi, could you please remove -1 here https://review.opendev.org/c/openstack/nova/+/933107 and provide your feedback ?
16:45:01 gibi ratailor: done
16:45:29 ratailor gibi, Thanks!
17:13:18 dansmith gibi: if you're still around.. it looks to me like we don't do all the "is this a physical function?" checking if the devspec is a pattern instead of a single device
17:14:02 dansmith I assume because there could be multiple things matched that have different characteristics
17:14:27 dansmith so you think we need to examine all the matching ones so we can abort if your spec matches a VF?
17:16:09 gibi auch. Yeah you are right, at that point we only have the dev_spec that can be wildcard and match to multiple devices. I'm not sure how the remote managed check below works then as that does some physical function check. Anyhow that means we cannot validate that input in at the device_spec parsing code and need to add it later in the pci_placemenet_translator
17:16:23 dansmith gibi: it just punts for patterns
17:16:36 gibi OK
17:16:40 dansmith gibi: well, my translator code already skips VFs
17:16:42 gibi not nice but meh
17:16:58 dansmith meaning, it won't reserve for VFs.. I could log something there though
17:17:43 sean-k-mooney we determin if its a phsyica function by looking at the libvirt nodedev xml when generiging the set of pci dicts and then we filter those by the devspec regexes ectra
17:17:45 gibi dansmith: yeah I think we can check in the translator that if the OTU is requested for a VF as that is clearly invalid. Currently your code ignoring it but that is missleading as the user expects that the OTU marked device will be reseved but it won't be
17:18:06 gibi so I suggest to raise there and let the deployer know that what is requested not supported

Earlier   Later