14:00:43 <jbernard> #startmeeting cinder
14:00:43 <opendevmeet> Meeting started Wed Jan 15 14:00:43 2025 UTC and is due to finish in 60 minutes.  The chair is jbernard. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:43 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:43 <opendevmeet> The meeting name has been set to 'cinder'
14:00:47 <jbernard> #topic roll call
14:00:49 <jbernard> o/
14:00:57 <abishop> o/
14:01:04 <josephillips> o/
14:01:06 <Luzi> o/
14:01:08 <simondodsley> o/
14:01:09 <sp-bmilanov> hi!
14:01:09 <sfernand> hi folks
14:01:14 <jungleboyj> o/
14:01:24 <rosmaita> o/
14:01:25 <msaravan> Hi
14:01:40 <jhorstmann> o/
14:01:51 <akawai> o/
14:02:14 <whoami-rajat_> Hi
14:03:35 <jbernard> hello everyone, thanks for joining
14:04:14 <jbernard> #link https://etherpad.opendev.org/p/cinder-epoxy-meetings
14:04:35 <jbernard> before we jump into the topic, quick schedule update
14:04:41 <jbernard> #link https://releases.openstack.org/epoxy/schedule.html
14:05:13 <jbernard> we are currently at M2
14:06:04 <simondodsley> quick question: Why are there no Cinder points on this schedule
14:06:06 <jbernard> final release is late march, but for coding we're looking at late feb
14:06:34 <jbernard> simondodsley: ahh that's an easy one :) i didn't create them :)
14:06:41 <josephillips> question in new on this meetings , to add a extra  topic of review can be checked here?
14:07:01 <simondodsley> lol - ok - F-cycle then...
14:07:03 <jbernard> josephillips: sure, just add it to the etherpad
14:07:30 <jbernard> josephillips: i scrape that each week and add it to my review list
14:08:01 <jbernard> simondodsley: this brings me to my point
14:08:20 <jbernard> aside from freezes, the important date we need to agree on is the midcycle
14:08:40 <jbernard> becasue I didnt set the date already, we have some flexibility
14:08:53 <yuval> o/
14:09:07 <simondodsley> why not just use he same as Manila
14:09:14 <jbernard> generally, late jan or early feb is ideal, to give enough runway to implement anything that comes out
14:09:17 <jbernard> simondodsley: that's fine with me
14:09:28 <jbernard> i wanted to raise it here
14:10:00 <jbernard> manilla midcyel is week R9 (jan 27)
14:10:06 <yuval> wait, so where is the feature code freeze?
14:10:56 <jbernard> yuval: feature freeze is R5 (feb 24)
14:11:04 <simondodsley> can we state the feature freeze here so we are all aware?
14:11:04 <yuval> got it
14:11:19 <simondodsley> oops
14:12:04 <jbernard> are there any conflicts or objections to repurposing our meeting into a midcycle the week of Jan 27?
14:12:19 <jbernard> jan 29 to be precise
14:12:30 <jbernard> (2 weeks from today)
14:13:07 <rosmaita> works for me
14:13:48 <jungleboyj> No concerns here.
14:13:57 <abishop> +1
14:14:22 <yuval> +1
14:14:25 <sfernand> +1
14:14:27 <josephillips> +1
14:14:51 <jbernard> ok, great
14:14:56 <jbernard> i will send a mail
14:15:04 <jbernard> thanks
14:15:34 <jbernard> #topic Enhanced Granularity and Live Applicationof Front-end QoS Policies
14:15:44 <jbernard> #link https://blueprints.launchpad.net/cinder/+spec/enhanced-granularity-and-live-application-of-frontend-qos-policies
14:16:02 <MengyangZhang[m]> Yes, I proposed this, just want to know if the community is interested in this feature
14:16:30 <MengyangZhang[m]> before we commit to implement it
14:17:29 <simondodsley> i love the idea of live changes to the QoS settings for a mounted volume.
14:18:17 <simondodsley> The project specific QoS is also a good idea. Pure has a patch up now to do exactly the same for our backend QoS
14:18:24 <jbernard> the summary looks good, is there anything like a spec, or more details on proposed implementation? that would likely be the next step
14:18:45 <abishop> but wouldn't that be something for nova to implement?
14:19:11 <MengyangZhang[m]> Yes that's the next step and indeed this is a cross project that also needs code changes on nova side.
14:19:19 <jbernard> abishop: i would assume nova would have to be involved, a spec should show that
14:19:56 <MengyangZhang[m]> I will try to create a similar bp on nova side and bring it up in next cinder-nova meeting
14:20:51 <abishop> conceptually it all sounds good, and clearly specs will cover a lot of details
14:20:51 <MengyangZhang[m]> simondodsley: great, is there a link to their patch?
14:20:52 <jbernard> MengyangZhang[m]: yeah, if nova has no objections then specs for cinder and nova would allow us to properly review
14:21:14 <simondodsley> https://review.opendev.org/c/openstack/cinder/+/933675
14:21:23 <MengyangZhang[m]> sounds good, i will bring it up in next nova meeting
14:21:51 <MengyangZhang[m]> MengyangZhang[m]: would love to learn how they did it
14:22:39 <rosmaita> MengyangZhang[m]: did your nova spec that we discussed last week get accepted?
14:23:29 <MengyangZhang[m]> it passed the code freeze period for them so i have to wait until next cycle
14:23:41 <MengyangZhang[m]> but overall they don't any objections about it
14:24:26 <whoami-rajat_> I think you can raise a spec freeze exception
14:24:30 <rosmaita> ok, bummer about the delay, sorry that we were slow to act on the cinder side
14:24:37 <whoami-rajat_> I remember sean mooney suggesting the same
14:26:08 <jbernard> ok, lets keep moving
14:26:16 <jbernard> #topic 936619: Dell PowerMax: multi detach req caused race conditions (rosmaita)
14:26:23 <rosmaita> hi
14:26:27 <jbernard> #link https://review.opendev.org/c/openstack/cinder/+/936619
14:26:49 <rosmaita> this is the latest in my weekly series of patches that have stalled
14:27:33 <rosmaita> the issue is that the dell driver maintainer wants this local fix that they say they have tested and is working
14:28:11 <rosmaita> while some cinder cores are wondering whether the patch is a band aid, and a more thorough fix is required
14:28:40 <rosmaita> i can see this both ways
14:29:20 <rosmaita> which is the problem, i guess
14:29:43 <whoami-rajat> the main worry here is that if we merge this and later some other deadlock occurs since we didn't fix this the proper way, we are again back to square 1
14:29:43 <rosmaita> what i would like is for us today to decide whether to accept the patch with reservations
14:29:46 <rosmaita> or require more work
14:31:33 <abishop> the topic pertains to coordination locks; currently there are lots of small locks around portions of the code, and the proposed fix would a new lock around a much larger operation
14:32:43 <jbernard> this is all local to the powermax driver
14:33:01 <rosmaita> right
14:33:59 <jbernard> there is significant backlog to read
14:34:15 <jbernard> the folks involved in the patch already, is there a consensus?
14:35:02 <rosmaita> well, yian has a comment that this top level lock that we don't like is actually correct for the backend
14:35:25 <rosmaita> https://review.opendev.org/c/openstack/cinder/+/936619/2#message-085723942bf6ec5a1e82390ec41a5a5c042fe12c
14:36:23 <rosmaita> that said, i am inclined to trust Rajat's intuition that this may not fix everything
14:36:47 <rosmaita> but, on the third hand, it's dell's driver and they do have an argument that this is an ok fix
14:37:00 <rosmaita> and that it's been tested and avoids the race condition
14:37:52 <abishop> that weighs in favor of Dell's patch, they own the solution but also any fallout/regression
14:38:11 <jbernard> ^ this is where i lean as well
14:38:21 <jbernard> but im not up to speed on this one
14:38:36 <rosmaita> i guess my feeling is that since this doesn't touch the main cinder code, and dell is convinced that it is correct, we probably shouldn't hold it up
14:38:39 <simondodsley> the comments mention OpenShift and also RHOSP - how are these related unless they mean RHOSO??
14:39:18 <simondodsley> and even then the dicconnects should be to the nova side which are not in pods
14:39:53 <whoami-rajat> their approach is not totally wrong, they want to only allow either attach or detach of one volume at one time, it's just the scope of the lock is too big
14:40:30 <whoami-rajat> I'm okay to remove my -1 if team thinks it's best to let the dell team handle the issue their way
14:42:00 <simondodsley> in general the fix sounds reasonable and it is a powermax specific issue so the core cinder code doesn't need to be affected
14:43:00 <jbernard> rosmaita, abishop? any strong feelings?
14:43:42 <abishop> I think reviewer concerns are noted, but am OK with Dell proceding with their patch
14:44:30 <rosmaita> i guess that's where i come down too ... Rajat's reasoning is explained well in his comment, and they will have something to go back to if the problem persists
14:44:40 <rosmaita> (i mean, something to refer to)
14:44:56 <jbernard> these are all good points
14:45:30 <jbernard> ok, this one can unblock then
14:45:45 <rosmaita> i think Rajat can keep his -1 if he likes
14:45:55 <jbernard> that's fair
14:46:01 <rosmaita> in fact, he should
14:46:14 <rosmaita> and then he can say "i told you so" after i +2 the patch
14:46:19 <jbernard> lol
14:46:20 <rosmaita> :D
14:46:38 <whoami-rajat> :D
14:46:44 <rosmaita> seriously, though, i do think leave the -1 to make it clear that you have reservations
14:46:45 <whoami-rajat> i removed it since it might discourage others to review it
14:46:46 <whoami-rajat> #link https://review.opendev.org/c/openstack/cinder/+/936619/2#message-dd5cb190790e5ab109d6712cc8f994d35c3d1aa4
14:47:09 <whoami-rajat> ok, should i will add it again then ...
14:47:45 <rosmaita> jbernard: i will review, will you be the 2nd reviewer?
14:48:08 <rosmaita> (i just don't want this patch to continue to sit now that we've decided how to proceed)
14:48:18 <jbernard> rosmaita: yes, i will have cycles this afternoon
14:48:36 <rosmaita> ok, great ... thanks everyone for the discussion, that's all from me
14:48:39 <whoami-rajat> done
14:48:41 <whoami-rajat> #link https://review.opendev.org/c/openstack/cinder/+/936619/2#message-af9ae0adbfebdb8276edea8ef6b4fd38748af0cc
14:48:49 <jbernard> cool
14:48:59 <jbernard> #topic open discussion
14:49:25 <flelain> Hey! Hope you guys are doing well!
14:49:37 <jbernard> flelain: thanks, you too!
14:49:53 <flelain> Don't know it that's the best slot but I have this pacth, staled for now: https://review.opendev.org/c/openstack/cinder/+/937526
14:50:08 <flelain> Yeah doing well thx!
14:50:39 <flelain> And sorry if it's not the best time and place :-/
14:51:06 <jbernard> flelain: rosmaita will likely follow up on that as he's reviewed it already
14:51:15 <sp-bmilanov> btw, last week there were talks of getting an internim os-brick release out, to help with getting Cinder changes in.. is that sill on the table?
14:51:17 <rosmaita> i think that patch is good, i just wanted to look into whether the new exception class is really necessary
14:51:27 <rosmaita> sp-bmilanov: i think it was released
14:51:38 <jbernard> i +1'd the hash
14:51:50 <whoami-rajat> we wouldn't even have that issue if nova cleaned up the leftover attachments during live migrate and other similar operations, but that's a long running discussion
14:51:58 <rosmaita> (i'm sure flelain is right about the exception, i was just surprised and wanted to look more closely)
14:53:05 <sp-bmilanov> rosmaita: where can I confirm this? The latest tag I see here is two months ago, but I might be looking at the wrong place: https://opendev.org/openstack/os-brick/tags
14:53:05 <rosmaita> sp-bmilanov: sorry, the release is ready but hasn't happened yet: https://review.opendev.org/c/openstack/releases/+/938578
14:53:15 <sp-bmilanov> ah, ok
14:53:23 <yuval> rosmaita I need to update my 3rd party ci wiki, but I keep failing the sign in: https://wiki.openstack.org/w/index.php?title=Special:OpenIDLogin&returnto=Main_Page
14:53:47 <yuval> can someone check if they are able to sign in - maybe its a running issue?
14:54:36 <rosmaita> yuval: i will check
14:54:58 <jbernard> yuval: i just logged in
14:55:07 <jbernard> yuval: seems to be sucessful for me
14:55:27 <sp-bmilanov> yuval: same as jbernard, I can log in
14:55:57 <rosmaita> me too
14:56:40 <josephillips> i have some doubts about this https://blueprints.launchpad.net/cinder/+spec/cinder-rbd-qos-total-iops-per-gb
14:56:51 <rosmaita> yuval: you were going to make the change we discussed yesterday?
14:57:09 <josephillips> if i should use the same keys that is on this documentation https://docs.openstack.org/cinder/latest/admin/capacity-based-qos.html
14:57:24 <rosmaita> yuval: i can edit the page now, and you can follow up with the infra team to get your login fixed
14:57:42 <whoami-rajat> josephillips, i think yes, you just need to set the consumer to back-end
14:57:58 <yuval> yes
14:58:05 <josephillips> yes i dunderstand that but my question is if i can use the same keys?
14:58:07 <yuval> yes please
14:58:36 <whoami-rajat> josephillips, are you planning to implement it? don't we already have back-end qos for rbd?
14:59:15 <josephillips> whoami-rajat yea i will going to implement it , not in a capacitive way
14:59:22 <rosmaita> yuval: got it
14:59:49 <josephillips> is not available whoami-rajat
14:59:51 <yuval> I see it
14:59:51 <yuval> 3rd party system: Lightbits CI
14:59:53 <yuval> Thanks
15:00:14 <whoami-rajat> josephillips, https://github.com/openstack/cinder/commit/f1bb51c25138a1aaab45b64e2934c0468b941677
15:00:39 <josephillips> yea but is static , nof depending the volume size
15:00:47 <rosmaita> yuval: let's see if the ciwatch picks that up, otherwise we can reach out to smcginnis
15:01:03 <yuval> http://cinderstats.ivehearditbothways.com/cireport.txt - maybe this need some time to be updated
15:01:04 <simondodsley> there is no per gb qos in ceph
15:01:16 <yuval> I will check it
15:01:37 <josephillips> yea but is static , nof depending the volume size whoami-rajat
15:01:40 <simondodsley> is that because ceph actually support this?
15:03:29 <josephillips> ceph support QoS simondodsley but only a static way , if you see another manufacters example netapp they provide a key to allow it dinamic depending of the volume size
15:03:34 <simondodsley> i'm not sure ceph supports per gb qos, so you will be limited to using the front-end qos that already exists
15:04:01 <jbernard> (we are over time, can we continue this in #openstack-cinder?)
15:04:07 <simondodsley> sure
15:04:31 <jbernard> ok, thanks everyone!
15:04:35 <jbernard> #endmeeting