Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-09-10
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
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>

Earlier   Later