| *** mhen_ is now known as mhen | 01:08 | |
| *** mhen_ is now known as mhen | 02:06 | |
| jbernard | #startmeeting cinder | 14:01 |
|---|---|---|
| opendevmeet | Meeting started Wed Sep 3 14:01:46 2025 UTC and is due to finish in 60 minutes. The chair is jbernard. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:01 |
| opendevmeet | The meeting name has been set to 'cinder' | 14:01 |
| jbernard | #topic roll call | 14:01 |
| jbernard | o/ | 14:01 |
| hvlcchao1 | o/ | 14:01 |
| agalica | o/ | 14:01 |
| vivek__ | o/ | 14:02 |
| jbernard | #link https://etherpad.opendev.org/p/cinder-flamingo-meetings | 14:02 |
| whoami-rajat__ | Hi | 14:02 |
| jayaanand | o/ | 14:02 |
| daksh | Hi can you guys please review IBM patches? | 14:02 |
| noonedeadpunk | o/ | 14:03 |
| simondodsley | o/ | 14:03 |
| Sai | o/ | 14:03 |
| simondodsley | dakash: make sure they arein the reviews etherpad and they we will looked at - there is a large backlog | 14:03 |
| flelain | o/ | 14:03 |
| rosmaita | o/ | 14:04 |
| gireesh | o/ | 14:04 |
| sfernand | hi | 14:06 |
| daksh | I have added the links of patches in https://etherpad.opendev.org/p/cinder-flamingo-meetings | 14:06 |
| jbernard | Ok, welcome everyone | 14:07 |
| simondodsley | daksh: i moved them to the review etherpad | 14:07 |
| jbernard | let's see here | 14:07 |
| noonedeadpunk | is reviews etherpad is mentioned somewhere to find it ? | 14:07 |
| noonedeadpunk | #link https://etherpad.opendev.org/p/cinder-flamingo-reviews | 14:08 |
| jbernard | daksh: im very aware of the ibm patches, i issued rechecks yesterday to get thing into shape, there should be movement today | 14:08 |
| jbernard | it's wednesday, already! :/ | 14:08 |
| noonedeadpunk | I know that it's here, but was not able to find it otherwise | 14:08 |
| daksh | Thanks jbernard...Kinda important for our release | 14:09 |
| noonedeadpunk | (like in https://docs.openstack.org/cinder/latest/contributor/contributing.html) | 14:09 |
| simondodsley | along with everyone elses... | 14:09 |
| agalica | Hi all - I'm from Hitachi. This is our first time doing this (we took over from Japan), and we didn’t anticipate how long it would take to get the CI going and reviews. In addition, the CI on the OpenDev server was completely broken the last couple days (timeouts and whatnot), and we were fighting that. We were wondering if and how we could get an exception / extension, and if so how we would go about that. This | 14:09 |
| flelain | simondodsley: +1 :P | 14:09 |
| agalica | l not be happy! I guess we're not the only ones with an important release, haha | 14:10 |
| jayaanand | i have to rebase due to merge conflict. can you please look at https://review.opendev.org/c/openstack/cinder/+/944964. Failed at gate job due to conflict | 14:11 |
| jbernard | we are in R-4 currently | 14:11 |
| jbernard | #link https://releases.openstack.org/flamingo/schedule.html | 14:11 |
| whoami-rajat__ | Sorry to interrupt but looks like the recent meetings have been full of review requests from the start of the meeting. There is a proper structure that we should follow and kindly wait for the open discussion section for such queries. Just sharing my thoughts. | 14:12 |
| jbernard | i still have some ibm patches to work on today, among many others | 14:12 |
| flelain | whoami-rajat: agreed | 14:12 |
| simondodsley | jbernanrd: are the other cores looking at patches as well? Seems like you are being left with a lot to do on your own | 14:13 |
| simondodsley | jbernard: ^ | 14:13 |
| jbernard | to my knowledge, yes | 14:13 |
| jbernard | rosmaita and I worked together yesterday for a bit looking over the SVF stuff | 14:13 |
| vdhakad | Hi Brian, I’ve addressed your comment on the patch https://review.opendev.org/c/openstack/cinder/+/925450. Could you please take another look when you get a chance? The +2 you provided yesterday is now outdated. | 14:14 |
| simondodsley | whoami-rajat__: probbaly because there are so mnay, it's close to freeze and people are concerned. | 14:14 |
| rosmaita | vdhakad: ok, that should be easy | 14:14 |
| noonedeadpunk | is that open disucssion type of the meeting? or some agenda is expected? | 14:14 |
| vdhakad | rosmaita: thanks! | 14:14 |
| jbernard | #topic annoucments | 14:14 |
| jbernard | sorry | 14:14 |
| simondodsley | i agree with whoami-rajat__ though. We should follow the structire and not just dump review requests in this meeting. The etherpad is there for a reason | 14:14 |
| jbernard | yes please | 14:15 |
| jbernard | ok, R-4 :) | 14:15 |
| jbernard | looking at feature patches that i we didn't have time for last week (holiday) | 14:16 |
| jbernard | and bug fixes | 14:16 |
| whoami-rajat__ | simondodsley: i understand but thats been the case since a long time and shouldn’t be the reason for it. I mean people dumping their review request all over the meeting won’t help getting any better attention to them. Sorry again and will let the meeting continue | 14:17 |
| jbernard | I wanted to remind everyone, | 14:18 |
| jbernard | if you create a release note that accompanies your changes, please make sure that it renders correctly | 14:18 |
| jbernard | there is a docs job that will run if you add or change a release note | 14:18 |
| jbernard | and a link there to the rendered result, it's worth looking at to make sure things look right (and good) | 14:18 |
| jbernard | that will save some time | 14:19 |
| jbernard | RC-1 is next week, so we have about 1 week remaining | 14:20 |
| jbernard | if you have time to do reviews of other patches, please do so, remember you can always ask questions / collaborate in our IRC channel | 14:21 |
| jbernard | that is all i have for annoucments, it's a very busy time with lots to do | 14:21 |
| jbernard | i am aware of the review needs, if there is something technical that needs to be worked out, this is the place | 14:22 |
| simondodsley | To all that are adding review requests to the etherpad, please use common courtesy and add you new requests to the bottom of the appropriate section (features or bugfixes), not to the top, just because you think it will get you higher priority. | 14:22 |
| jbernard | for general review requests, i look at the etherpad daily, that is the place for those | 14:23 |
| cardoe | So is there any hash tag used for review priority or ordering in gerrit? | 14:23 |
| * noonedeadpunk have a question regarding general collaboration approaches on feature-related patches and spec/spec-less | 14:24 | |
| cardoe | Yeah what noonedeadpunk said. | 14:24 |
| agalica | Hi jbernard -- I'm with Hitachi and I'm trying to get clarity on the release and whether or not we would need an extension or not. We're passing Zuul and local tempest tests, but do not have a CI to upload tests, nor the reviews required (need reviews!) | 14:24 |
| jbernard | cardoe: there is the Review-Priority vote on the patch itself | 14:24 |
| jbernard | cardoe: is that what you're looking for? | 14:25 |
| jbernard | noonedeadpunk: shoot | 14:25 |
| noonedeadpunk | question: If I want to add configuration option to cinder-backup - does it require a spec to be written, or jsut a blueprint woudl be enough? | 14:25 |
| noonedeadpunk | for instance I come up with https://review.opendev.org/c/openstack/cinder-specs/+/958838/2/specs/2026.1/restrict-backup-container-creation.rst | 14:26 |
| jbernard | agalica: it depends on the content of the change mostly, CI is generally required, but i would need to know more | 14:26 |
| cardoe | Honestly just looking to start getting engaged. I'll likely have a team member be the main person. I've just been following some patches which get reviews and pass tests but haven't necessarily landed. | 14:26 |
| noonedeadpunk | but it's quite a trivial change/feature to implement | 14:26 |
| cardoe | In Ironic we add a hashtag "ironic-week-prio" and that's what folks can search for to review. | 14:26 |
| noonedeadpunk | and now I see that simmilar things are going spec-less | 14:26 |
| agalica | jbernard: we added new featuers, and can provide CI output to show that the CI passes. Problematically, we underestimated the time it would take to get all of this running, along with a escalation that came up at the worst time. So, we have passing CI and can provide evidence of such | 14:27 |
| agalica | We have our 3 patches in the etherpad. They had been added to the top, but I moved them lower (wasn't even thinking they'd be higher priority at the top) | 14:27 |
| jbernard | cardoe: can you link me an example? | 14:27 |
| jbernard | noonedeadpunk: generally we /should/ have a spec, even if it's not particularly verbose | 14:28 |
| cardoe | https://review.opendev.org/c/openstack/ironic/+/954755 | 14:28 |
| jbernard | noonedeadpunk: it helps with tracking, cycle highlights, and release notes | 14:28 |
| noonedeadpunk | ++ | 14:28 |
| jbernard | noonedeadpunk: and seperating bugs from driver features, to general feature work | 14:28 |
| simondodsley | i like the hashtag idea, but who has permission to set it? Can't have everything adding the hashtag or it becomes pointless | 14:29 |
| agalica | jbernard: new features are: new array, replication, snapshot resizing | 14:29 |
| jbernard | agalica: i cant make any promises, but if it's on the ehterpad ill at least look at it and try to comment with what we may need | 14:30 |
| noonedeadpunk | TL;DR the spec is regarding adding an option `backup_create_containers` for operators to limit ability of creating new paths on backends by users. IS that overall sound like a sane idea? I'm not asking for review now or anything, but more of a quick vibe check :) | 14:30 |
| jbernard | simondodsley: we have Review-Priority, which i think cores can manipulate | 14:30 |
| agalica | jbernard: ok, thank you. It would mean a lot as this is a very important release (like everyone else's) | 14:31 |
| simondodsley | jbernard: agreed, but i don't see it being leveraged that often | 14:31 |
| jbernard | agalica: there /should/ be CI for things like that | 14:31 |
| agalica | jbernard: yes, I know. We do have the CI working manually, just not set up to upload | 14:31 |
| agalica | (or automated) | 14:31 |
| agalica | we have a PuTTy log of the tempest output and can provide other formats if necessary | 14:32 |
| simondodsley | agalica: it has to be automated so that gerrit can kick it off to run cinder and os-brick patches for things other than your own patches | 14:32 |
| jbernard | cardoe, simondodsley: i will look at how ironic manage it | 14:32 |
| agalica | simondodsley: understood. That will be one of the first things we do after this patch is behind us | 14:33 |
| * Anoop_Shukla Need reviews for the Patch: https://review.opendev.org/c/openstack/cinder/+/956221 This has NetApp CI and NetApp approvals. Need core team to take a look at the patch.. | 14:33 | |
| cardoe | We actually let anyone set it but the cores police it. | 14:33 |
| noonedeadpunk | everyone can set a hashtag | 14:33 |
| noonedeadpunk | afaiuk | 14:33 |
| agalica | We aren't trying to get out of it, we simply ran out of time for this (but we pass CI locally with our storage, and have QAd the code, of course) | 14:33 |
| noonedeadpunk | but it would be really nice to place a review etherpad to some searchable place | 14:34 |
| jbernard | cardoe: im willing to consider it, but the biggest concern is that it becomes another thing to do - and we have plenty of those already :) | 14:34 |
| simondodsley | cardoe: seems like an extra layer of core management when they don't have the time to do the current stuff, including Review-Priority | 14:34 |
| noonedeadpunk | and having it mentioned on contributors page would be really nice | 14:34 |
| cardoe | Not asking ya to change. | 14:34 |
| cardoe | I just didn't know about the review etherpad | 14:34 |
| noonedeadpunk | ++ ^ | 14:34 |
| jbernard | the problem with review-priority is that the reviewer may not know what the priority is for the submitter | 14:35 |
| cardoe | Like noonedeadpunk said if it was linked that was good. | 14:35 |
| jbernard | it would be helpful if, given a largish set of patches, to know exactly which ones were most important | 14:35 |
| noonedeadpunk | I spent like 10 mins for sure to search for the link after you mentioned there is some etherpad for it | 14:35 |
| simondodsley | it's in the main meeting agenda etherpad now | 14:36 |
| cardoe | sorry have a 1:1 with my boss right now so multi-tasking and failing | 14:36 |
| jbernard | cardoe: no worries, thanks for the input | 14:37 |
| jbernard | noonedeadpunk: sorry, i thought it was in the etherpad header, but i was wrong. It's there now | 14:37 |
| noonedeadpunk | nice | 14:38 |
| noonedeadpunk | thanks ! | 14:38 |
| agalica | jbernard: Please do not take this as rushing you, but do you maybe have an ETA on when you can let us know what we need to provide you (if possible)? If you do not know, that is ok. I just need to write up a report for my boss as to the steps we're taking | 14:42 |
| jbernard | agalica: you need automated CI, this is our policy | 14:43 |
| agalica | ok. If we can set that up this week, can we still get in the release? | 14:43 |
| jbernard | agalica: we make occasional exceptions, but i am worried about that being used to often | 14:43 |
| jbernard | agalica: it depends on the size and complexity of the patches, and wether they're in really good shape, not to mention all of the other patches that have been waiting longer... impossible, no; but probably unlikely given where we are at in the release cycle. techincally features are frozen and we're looking at bug fixes now | 14:45 |
| agalica | ok, thanks | 14:46 |
| jbernard | we have 10 minutes remaining, but if there is nothing else, we can all get back to it, last call | 14:51 |
| jayaanand | NetApp patch https://review.opendev.org/c/openstack/cinder/+/944964 failed at gate job due to merge conflict. Need re-look from core reviewers | 14:52 |
| jbernard | jayaanand: ack | 14:53 |
| jayaanand | Thank you! | 14:53 |
| jbernard | ok, thank you everyone, see you in #openstack-cinder if you need anything | 14:55 |
| jbernard | #endmeeting | 14:55 |
| opendevmeet | Meeting ended Wed Sep 3 14:55:15 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:55 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/cinder/2025/cinder.2025-09-03-14.01.html | 14:55 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/cinder/2025/cinder.2025-09-03-14.01.txt | 14:55 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/cinder/2025/cinder.2025-09-03-14.01.log.html | 14:55 |
| cardoe | Apologies. Just hung up with the boss. | 15:12 |
| cardoe | The patch jayaanand posted is one I'm interested in. | 15:19 |
| cardoe | Not sure if I should speak here or #openstack-cinder | 15:19 |
| cardoe | But my use case today is around a NetApp and OpenStack Ironic. | 15:20 |
| cardoe | My initial usage is not for BFS (boot from storage) but instead adding additional volumes. | 15:20 |
| cardoe | There's a lot of interaction there where we just pass JSON-ified dicts around and the keys/fields don't line up. | 15:21 |
| cardoe | The NetApp driver is a bit inconsistent itself in some of the fields. e.g. you can even see it in that patch... https://review.opendev.org/c/openstack/cinder/+/944964/11/cinder/volume/drivers/netapp/dataontap/nvme_library.py | 15:22 |
| cardoe | So the pool fields are just a raw dict but using different protocols with the NetApp leads to different fields depending on which actual backend driver implemented the request since they use a proxy driver. | 15:23 |
| cardoe | We're using NVMe, which is only supported via REST but we still had to provide a SSH key. | 15:28 |
| cardoe | Digging into the behavior, that's because the NetApp drivers don't advertise what options they use but instead come through... https://opendev.org/openstack/cinder/src/commit/92c645f1f1e913b5b1cd8ad0227a251f03adec04/cinder/volume/drivers/netapp/dataontap/utils/utils.py#L70 to load the client which calls | 15:29 |
| cardoe | https://opendev.org/openstack/cinder/src/commit/92c645f1f1e913b5b1cd8ad0227a251f03adec04/cinder/volume/drivers/netapp/dataontap/utils/utils.py#L40 which always loads all the options | 15:29 |
| cardoe | Which okay, the RestClient is forcibly loaded by the NVMe side but still wanted SSH so looking further... | 15:30 |
| cardoe | The RestClient always loads a copy of the SSH client... https://opendev.org/openstack/cinder/src/commit/92c645f1f1e913b5b1cd8ad0227a251f03adec04/cinder/volume/drivers/netapp/dataontap/client/client_cmode_rest.py#L66 | 15:30 |
| cardoe | And there's like one call that get_volume_stats() hits which isn't supported via REST so it falls back. It's just to provide a dedup percentage. | 15:31 |
| cardoe | There's just a lot of circular logic and loading adding to the complexity. | 15:31 |
| cardoe | I see that https://opendev.org/openstack/cinder/src/commit/92c645f1f1e913b5b1cd8ad0227a251f03adec04/cinder/volume/driver.py#L637 exists and was wondering if maybe that should be enforced to provide what each driver will use option wise? | 15:32 |
| cardoe | Similarly I see https://opendev.org/openstack/cinder/src/commit/92c645f1f1e913b5b1cd8ad0227a251f03adec04/cinder/volume/driver.py#L452 which takes *args and **kwargs and seems to imply some parameters are optional like "configuration" but if you really look I don't think any driver actually allows that to not be supplied now days so should it be required? | 15:34 |
| cardoe | https://opendev.org/openstack/cinder/src/commit/92c645f1f1e913b5b1cd8ad0227a251f03adec04/cinder/volume/manager.py#L311 is where the driver is loaded and has the parameters passed to it. So you'll see "configuration" is always supplied. | 15:35 |
| cardoe | BaseVD.__init__ could call get_driver_options and load that into configuration for all drivers. | 15:37 |
| cardoe | It seems like it would clean up quite a bit of code that's duplicated and done differently in all the other drivers. | 15:38 |
| jbernard | cardoe: our main #openstack-cinder channel is best | 16:43 |
| jbernard | we just just this one for meetings | 16:43 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!