| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-09-10 | |||
| 16:28:02 | bauzas | elodilles: thanks, just adding your nova rc1 patch to the etherpad :) | |
| 16:28:14 | elodilles | ++ | |
| 16:29:18 | bauzas | also, | |
| 16:29:43 | bauzas | maybe people forgot here that as soon as we branch master with RC1, then master becomes Epoxy :) | |
| 16:29:50 | bauzas | accordingly | |
| 16:30:04 | bauzas | #info Epoxy development phase will start as soon as we branch RC1 | |
| 16:30:21 | bauzas | #link https://releases.openstack.org/epoxy/schedule.html | |
| 16:30:44 | bauzas | and accordingly, we'll use another etherpad for tracking all the work we'll be doing for Epoxy : | |
| 16:30:54 | bauzas | #link https://etherpad.opendev.org/p/nova-2025.1-status | |
| 16:31:23 | bauzas | feel free to add any blueprints you would want us to look at or any bug report you'd want to fix by Epoxy timeframe | |
| 16:32:04 | bauzas | based on my discussions at the OIF Summit Asia, I was also convinced to update our docs to mention our tracking system | |
| 16:32:25 | bauzas | #action bauzas to update the contributor docs to mention the etherpad and how to reach the nova community | |
| 16:33:11 | bauzas | that's it for me for release planning | |
| 16:33:20 | bauzas | anything else to add ? | |
| 16:33:30 | bauzas | oh | |
| 16:33:35 | bauzas | I forgot | |
| 16:33:53 | bauzas | in the rc tracking etherpad, I have a couple of patches I'd beg cores to review | |
| 16:34:12 | gibi | I went through that list so we need one more cores | |
| 16:34:20 | bauzas | particularly the highlights | |
| 16:34:23 | gibi | s/cores/core/ | |
| 16:34:27 | bauzas | gibi: thanks ! | |
| 16:34:57 | gmann | I +w few of them | |
| 16:35:13 | bauzas | gmann: thanks too | |
| 16:35:26 | bauzas | okay, I'll chase the patches and bug people eventually | |
| 16:35:29 | bauzas | moving on then | |
| 16:35:38 | bauzas | #topic Review priorities | |
| 16:35:59 | bauzas | this is currently punted to once we branch RC1 | |
| 16:36:35 | bauzas | the current priorities are now clearly bugfixes, particularly if they are regression ones :) | |
| 16:36:47 | bauzas | #topic Stable Branches | |
| 16:36:55 | bauzas | elodilles: take the baton | |
| 16:36:59 | elodilles | o7 | |
| 16:37:02 | elodilles | #info stable/202*.* gates seem to be OK | |
| 16:37:16 | elodilles | #info stable/2024.2 branch were cut for libraries | |
| 16:37:44 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:38:19 | elodilles | please add gate errors in the pad if anyone finds one ^^^ | |
| 16:38:35 | elodilles | and that's all about stable branches from me | |
| 16:39:14 | bauzas | all good | |
| 16:39:34 | bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | |
| 16:39:37 | fwiesel | #info No updates. | |
| 16:39:38 | bauzas | fwiesel: your time | |
| 16:39:42 | bauzas | cool with me | |
| 16:39:53 | bauzas | #topic Open discussion | |
| 16:40:14 | bauzas | we have one time that was carried over from last week, I'd say | |
| 16:40:16 | bauzas | (whoami-rajat) Add multipath_id to the BDM in case of iSCSI | |
| 16:40:25 | bauzas | whoami-rajat: are you available now ? | |
| 16:41:21 | sean-k-mooney | gibi and i have looked at the patch | |
| 16:41:40 | sean-k-mooney | effectivly they want to do this to make debuging with db dubps simplere | |
| 16:41:58 | sean-k-mooney | apprently only nova and the network backend has the multipath_id | |
| 16:42:10 | bauzas | orly? | |
| 16:42:25 | sean-k-mooney | and this is useful for them to be able to corralate the instance and the volume on the storage backend | |
| 16:42:51 | sean-k-mooney | im a little reluctant to add the multipath id just for debuging but not 100% agisnt it | |
| 16:43:01 | sean-k-mooney | i left a comment to that effect on the patch | |
| 16:43:18 | bauzas | and I guess the BDM is a blob ? | |
| 16:43:37 | bauzas | no database update needs ? | |
| 16:44:02 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/889257 | |
| 16:44:15 | sean-k-mooney | its a json blob i belive yes | |
| 16:44:46 | bauzas | I don't get why we need to persist it | |
| 16:44:55 | bauzas | couldn't we show it in the logs ? | |
| 16:45:00 | gibi | It feels wrong that nova perists a data that nova never uses and never passes along | |
| 16:45:30 | sean-k-mooney | hum https://github.com/openstack/nova/blob/master/nova/db/main/models.py#L684-L754 | |
| 16:45:30 | bauzas | agreed with gibi | |
| 16:45:48 | sean-k-mooney | i guess this would be in connection_info | |
| 16:45:54 | bauzas | yeah | |
| 16:46:01 | bauzas | that's where they're stuffing it into | |
| 16:46:09 | bauzas | and that's a text filed | |
| 16:46:12 | bauzas | field | |
| 16:46:12 | sean-k-mooney | ya so im not a fan of that either | |
| 16:46:18 | bauzas | but I don't like persisting it | |
| 16:46:27 | sean-k-mooney | this is also in teh vm xml | |
| 16:46:35 | bauzas | for multiple reasons, the first one being that this info couldn't be reliable | |
| 16:46:50 | sean-k-mooney | the storage folk apparently use db dumps for debugging more then we do | |
| 16:46:58 | sean-k-mooney | i value having it in the logs and xml more | |
| 16:47:03 | gibi | hm, if this is in the xml then a proper sos report has enough info to correlate multipath_id with volume and instance | |
| 16:47:07 | sean-k-mooney | becuase we normally dont have db dumps | |
| 16:47:10 | bauzas | even with all we know about orphaned BDMs ? | |
| 16:47:39 | gibi | or they need historical data about delete VMs? | |
| 16:47:51 | bauzas | logs will tell you tho | |
| 16:47:58 | gibi | yeah we dump the xml to debug | |
| 16:48:01 | sean-k-mooney | bauzas: to move this forward can i suggest reaching out to rajat | |
| 16:48:09 | gibi | yeah we need rajat for this | |
| 16:48:10 | bauzas | also | |
| 16:48:16 | sean-k-mooney | or putting it on the ptg topic list | |
| 16:48:32 | bauzas | this would require a blueprint at least, maybe a spec if we consider the DB change | |
| 16:48:55 | bauzas | the fact that nothing in nova reads that value makes me very reluctant at least | |
| 16:49:13 | sean-k-mooney | ya i was -1 on thi initally when i spoke to them on slack and asked them ot bring it upstream | |
| 16:49:17 | bauzas | I don't want us to create a precedent with any text field just being a brown bag for DB bumps | |
| 16:49:21 | bauzas | dumps* | |
| 16:49:24 | sean-k-mooney | i agree this is not a bug but a minor feature | |
| 16:49:51 | sean-k-mooney | to me this is out os scope but i think we should let them present there case | |
| 16:50:07 | bauzas | then we can write an AI | |
| 16:50:18 | opendevreview | Balazs Gibizer proposed openstack/nova master: [doc]Developer doc about PCI and SRIOV testing https://review.opendev.org/c/openstack/nova/+/928834 | |
| 16:51:07 | bauzas | #agreed this case sounds a feature request and requires a blueprint, which would describe the reason for that change and the solution | |
| 16:51:09 | dansmith | a db change for a thing we don't actually need would require a lot of justification for me to get behind :) | |
| 16:51:42 | bauzas | #agreed this blueprint would have to be discussed in a later nova meeting to see whether it would be specless or requiring a spec | |
| 16:51:52 | bauzas | dansmith: I think the meeting logs are clear :) | |
| 16:52:21 | bauzas | tbc, if nothing reads that BDM value, this is tech debt | |
| 16:52:22 | dansmith | yep, just chiming in | |
| 16:52:43 | bauzas | cool | |
| 16:52:52 | bauzas | I hope whoami-rajat will read the logs | |
| 16:52:57 | bauzas | and again, I'm open to chat | |