| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-09-10 | |||
| 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 | |
| 16:53:15 | bauzas | I think we're settled | |
| 16:53:29 | bauzas | any carried over item from last week or any new meat to digest ? | |
| 16:53:38 | bauzas | or can I call it a wrap and take a beer ? | |
| 16:54:07 | opendevreview | Balazs Gibizer proposed openstack/nova master: [doc]Developer doc about PCI and SRIOV testing https://review.opendev.org/c/openstack/nova/+/928834 | |
| 16:54:25 | sean-k-mooney | we had one other item | |
| 16:54:38 | sean-k-mooney | can we reappove the shared security group specless blueprint | |
| 16:54:41 | sean-k-mooney | for expoy | |
| 16:54:48 | sean-k-mooney | https://blueprints.launchpad.net/nova/+spec/shared-security-groups | |
| 16:55:00 | bauzas | thanks | |
| 16:55:09 | bauzas | I haven't seen it in the agenda | |
| 16:55:18 | bauzas | I have no objection for the reapproval | |
| 16:55:26 | sean-k-mooney | i think the current state of the patch is mergable, this is the one i pinged about at the start of the meeting | |
| 16:55:38 | sean-k-mooney | so it would be a easy win after rc1 | |
| 16:55:51 | bauzas | sounds a quickwin as soon as RC1 branches | |
| 16:56:00 | bauzas | yeah | |
| 16:56:12 | bauzas | okay, don't hear any disagreement, so... | |
| 16:57:00 | bauzas | #agreed https://blueprints.launchpad.net/nova/+spec/shared-security-groups is accepted again as specless bp for Epoxy | |
| 16:57:09 | bauzas | that's it for me | |
| 16:57:14 | bauzas | and we're at time | |
| 16:57:22 | bauzas | thanks all | |
| 16:57:27 | bauzas | #endmeeting | |
| 16:57:27 | opendevmeet | Meeting ended Tue Sep 10 16:57:27 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:57:27 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-09-10-16.01.html | |
| 16:57:27 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-09-10-16.01.txt | |
| 16:57:27 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-09-10-16.01.log.html | |
| 16:57:37 | sean-k-mooney | o/ ok ill brb | |
| 16:57:54 | gibi | bauzas: thanks | |
| 16:58:06 | elodilles | thanks o/ | |
| 17:05:15 | opendevreview | Merged openstack/os-vif stable/2024.2: Update TOX_CONSTRAINTS_FILE for stable/2024.2 https://review.opendev.org/c/openstack/os-vif/+/928355 | |
| 17:08:04 | opendevreview | Dmitriy Rabotyagov proposed openstack/nova master: Respect supplied arguments in novncproxy_base_url https://review.opendev.org/c/openstack/nova/+/928839 | |
| 17:08:33 | noonedeadpunk | sean-k-mooney: this is what we were discussing yesterday ^ | |
| 17:10:06 | sean-k-mooney | ya so either parsing it like that or a sperate config option just for the extra query args | |
| 17:10:23 | sean-k-mooney | that does not look unreasonabel to me at a glance | |
| 17:11:00 | sean-k-mooney | although im not a fan of puting each arg on its own line like this https://review.opendev.org/c/openstack/nova/+/928839/1/nova/tests/unit/objects/test_console_auth_token.py#103 | |
| 17:11:19 | sean-k-mooney | that proably a trivial specless bluepirnt | |
| 17:11:39 | sean-k-mooney | so we will need to put it on the adgenda for next week | |
| 17:11:42 | sean-k-mooney | bauzas: ^ | |
| 17:12:21 | sean-k-mooney | anyway for a 30 second review i think its ok over all but ill need to loop back to that properly later | |
| 17:14:57 | sean-k-mooney | noonedeadpunk: would you mind filing a specless bluepint and updating the commit message with implements: blueprint <name> | |
| 17:15:08 | sean-k-mooney | and queing that up for next week adjenda | |
| 17:19:08 | noonedeadpunk | regarding tests - I was pretty much following the pattern from `_test_authorize` | |
| 17:19:47 | sean-k-mooney | ya we are kind of inconsitentent | |
| 17:19:52 | noonedeadpunk | ah, sorry | |
| 17:20:00 | noonedeadpunk | I thought about different line | |
| 17:20:21 | noonedeadpunk | all args in one line were exceeding the 80l | |
| 17:20:38 | sean-k-mooney | yep so we normally put them all on the next line | |
| 17:20:53 | sean-k-mooney | that allow you to reclaim all the indent space | |
| 17:21:02 | noonedeadpunk | ++ | |
| 17:21:41 | sean-k-mooney | so like this https://peps.python.org/pep-0008/#indentation | |
| 17:22:51 | sean-k-mooney | so "Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest." | |
| 17:23:09 | noonedeadpunk | yeah, I got it :) | |
| 17:23:20 | sean-k-mooney | to be fair i want to just automate this | |
| 17:23:30 | sean-k-mooney | but we have never got agreement on how | |
| 17:23:53 | sean-k-mooney | but im very tempeted to review my black serise with line lenght 79 | |
| 17:24:09 | sean-k-mooney | i dont like black but i disliek discussion formatign with humans more :) | |
| 17:24:26 | sean-k-mooney | let the bots/tools fight that out instead | |
| 17:25:06 | whoami-rajat | sorry everyone, i wasn't around for the meeting, but would like to address a few of the concerns | |
| 17:25:11 | whoami-rajat | bauzas, it's a challenge to figure out where we want to log it, customer deployments don't enable DEBUG by default and there are multiple failure scenarios where we would need to log this in case of an exception | |
| 17:25:11 | whoami-rajat | bauzas, also I'm not sure why it is not reliable? the multipath_id or WWID is the ID assigned to the volume (LUN) so it is persistent throughout the life of the volume across multiple attach/detach cycles | |
| 17:25:11 | whoami-rajat | dansmith, So for fibre channel connections, we already store the multipath_id in the connection_info field, my patch is just adding it for iSCSI connections, not sure if it still counts as a DB change, more of filling a missing value for one type of attachments (iSCSI) | |
| 17:25:12 | whoami-rajat | Also I've found this value being used in the LUKS encryptor, https://github.com/openstack/os-brick/blob/master/os_brick/encryptors/luks.py#L89-L98 | |
| 17:25:35 | sean-k-mooney | whoami-rajat: they do not for 18 but historically yoru correct | |
| 17:25:40 | sean-k-mooney | *the do now | |
| 17:26:02 | noonedeadpunk | sean-k-mooney: about specless blueprint - so it's just a record on launchpad with description? | |