14:00:27 <rosmaita> #startmeeting cinder
14:00:27 <opendevmeet> Meeting started Wed Sep  8 14:00:27 2021 UTC and is due to finish in 60 minutes.  The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:27 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:27 <opendevmeet> The meeting name has been set to 'cinder'
14:00:33 <rosmaita> #topic roll call
14:00:47 <walshh_> hi
14:00:48 <fabiooliveira> hi
14:00:51 <whoami-rajat> Hi
14:00:51 <shoffmann> hi
14:00:58 <eharney> hi
14:01:08 <enriquetaso> hi
14:01:09 <zoharm> hi
14:01:17 <hemna> yough
14:01:47 <jungleboyj> o/
14:02:22 <rosmaita> looks like a decent turnout
14:02:31 <rosmaita> #link https://etherpad.opendev.org/p/cinder-xena-meetings
14:02:35 <tosky> o/
14:02:38 <rosmaita> #topic announcements
14:02:59 <rosmaita> first up, the client libraries were released last week
14:03:04 <rosmaita> python-cinderclient 8.1.0, python-brick-cinderclient-ext 1.4.0
14:03:20 <rosmaita> just like with os-brick, the stable/xena branch has been cut for each
14:03:32 <rosmaita> so, any critical bugfixes need to go to master first and then be backported
14:03:59 <rosmaita> next announcement: we are under Feature Freeze
14:04:08 <rosmaita> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-September/024651.html
14:04:26 <rosmaita> that means no features merge to master until after the stable/xena branch is cut
14:04:31 <jungleboyj> Stop!  In the name of stability ... before you break our build ...
14:04:42 <rosmaita> also, avoid changing any translatable strings
14:04:55 <rosmaita> log messages aren't translated, so those can be changed at any time
14:05:15 <rosmaita> the deadline to apply for Feature Freeze Exceptions was yesterday
14:05:21 <rosmaita> we had some applications
14:05:32 <rosmaita> #link https://etherpad.opendev.org/p/cinder-xena-ffe
14:06:09 <rosmaita> the stuff on that etherpad ^^ are the highest priority for the rest of the week
14:06:33 <rosmaita> i put some status notes on the etherpad to keep everyone informed
14:06:55 <rosmaita> any questions?
14:07:44 <rosmaita> apparently not
14:07:50 <zoharm> yes please hahah
14:07:59 <jungleboyj> rosmaita:  Thank you for putting that together.  Very helpful.
14:08:00 <zoharm> bugfixes need to go into ffe?
14:08:21 <rosmaita> no, bugfixes do not need an FFE
14:08:31 <zoharm> okm thank you
14:08:51 <rosmaita> but what will happen is that when we release RC-1, only release-critical bugs will be allowed into master and then backported to stable/xena
14:09:27 <rosmaita> so, if you are working on a "normal" bug, make sure you have all merge conflicts resolved, CI looks good, etc. before RC-1
14:09:36 <rosmaita> which is the next item:
14:09:46 <rosmaita> RC-1 will be cut next Thursday
14:10:08 <rosmaita> so we are really winding down the Xena cycle
14:10:23 <rosmaita> and, it's time to start thinking about Yoga
14:10:24 <jungleboyj> Where has the time gone?
14:10:29 <rosmaita> no kidding
14:10:51 <rosmaita> we need to open up the specs repo for yoga: https://review.opendev.org/c/openstack/cinder-specs/+/806567
14:11:17 <rosmaita> that's a minor patch, so i think one +2 is enough to merge it
14:11:25 <rosmaita> (but it needs one +2!)
14:11:35 <rosmaita> also, we have the planning etherpad:
14:11:42 <rosmaita> #link https://etherpad.opendev.org/p/yoga-ptg-cinder-planning
14:12:00 * jungleboyj is looking.
14:12:03 <rosmaita> if you've been following the mailing list, there are at least 3 topics from outside our close-knit team
14:12:16 <rosmaita> so that's good, should be some interesting stuff discussed
14:12:40 <rosmaita> as usual, don't forget to register for the PTG ... it's free, etc.
14:13:15 <rosmaita> ok, that's all from me ... did i forget anything, or any questions?
14:14:03 <rosmaita> guess not ... moving along, then
14:14:17 <rosmaita> #topic nas_secure file access with cinder user
14:14:20 <rosmaita> shoffmann: that's you
14:14:27 <shoffmann> Hi thanks.
14:14:57 <shoffmann> Sorry to bother again, would be nice to know, if I'm on the right path with it now or there is a better approach.
14:15:26 <shoffmann> We started some discussion, what the nas_secure options can be used for https://etherpad.opendev.org/p/gSotXYAZ3JfJE8FEpMpS
14:15:26 <eharney> i still have the etherpad about this open and need to spend some time on it... sorry i haven't gotten back with anything yet :/
14:15:46 <shoffmann> ok, thanks
14:16:28 <shoffmann> But last time we already saw, that using this options and how to access files may not be depended.
14:17:12 <shoffmann> So I updated the Change to look on the option and than try to open files using the cinder user, if it fails use the root user.
14:17:33 <shoffmann> We can continue this topic, when you had time for it.
14:17:40 <shoffmann> That's from my side.
14:17:46 <rosmaita> thank you
14:18:07 <rosmaita> sfernand: i think you may have already left comments on the etherpad?
14:18:15 <rosmaita> if not, please take a look
14:18:28 <enriquetaso> #link https://etherpad.opendev.org/p/gSotXYAZ3JfJE8FEpMpS
14:18:34 <rosmaita> ty
14:19:05 <rosmaita> #topic removing lower-constraints job and file from master
14:19:10 <rosmaita> we agreed to do this a while back
14:19:20 <rosmaita> but there are 2 patches languishing
14:19:28 <rosmaita> #link https://review.opendev.org/c/openstack/cinderlib/+/799913
14:19:36 <rosmaita> #link https://review.opendev.org/c/openstack/rbd-iscsi-client/+/799914
14:19:58 <rosmaita> i would like to get these out of the way, please
14:20:33 <rosmaita> i believe that they are uncontroversial, but if anyone sees a problem (and that's why they're not reviewing), please leave a comment
14:21:24 <rosmaita> unless anyone has an objection, i am willing to merge either of those with only one +2
14:21:29 <rosmaita> but hopefully it won't come to that
14:21:35 <jungleboyj> rosmaita:  I will take a look.
14:21:39 <rosmaita> ty
14:21:59 <rosmaita> #topic deprecate RateLimitingMiddleware
14:22:13 <rosmaita> this is timely because if we are going to deprecate it, we need to do it right now
14:22:22 <rosmaita> #link https://bugs.launchpad.net/cinder/+bug/1942696
14:22:31 <rosmaita> #link https://review.opendev.org/c/openstack/cinder/+/807469
14:23:12 <rosmaita> so, the short version is that Takashi noticed that the rate limiting middleware depends on a cinder.v2 class, that we probably want to get rid of or migrate to v3
14:23:26 <rosmaita> but then he noticed that nobody is probably using this anyway
14:23:41 <rosmaita> so instead of move it to v3, maybe we should deprecate it in Xena and remove it in Yoga
14:24:22 <rosmaita> i think the key issue is that if you have multiple API nodes, the middleware doesn't really work, and if you have multiple API nodes, the rate limiting is being done somewhere else anyway
14:24:27 <eharney> how many other projects support this?
14:24:40 <rosmaita> well, it was part of nova, and they don't have it any more
14:24:52 <rosmaita> pretty sure glance doesn't have it
14:24:57 <eharney> i don't really agree that it doesn't work with multiple nodes... it might be less accurate but can still achieve what people would want it for
14:25:00 <jungleboyj> Would seem like a good idea to deprecate it then.
14:25:07 <eharney> but, i don't know if people actually use it
14:25:55 <rosmaita> ok, tell you what ... i will post something to the ML today with [operators] in the subject line asking about this
14:26:15 <rosmaita> then we can decide next week
14:26:16 <eharney> removing it because nobody uses it is fine, but i think the technical reasons listed aren't a great justification to
14:26:45 <rosmaita> in the mean time, would be worth looking at the patch to see if the deprecation approach is OK (assuming we decide to deprecate)
14:26:59 <rosmaita> because we will be really close to RC-1 at the next meeting
14:27:33 <rosmaita> any other comments?
14:27:59 <rosmaita> #action rosmaita - email to [ops] about whether anyone is using RateLimitingMiddleware with cinder
14:28:33 <rosmaita> #topic third party CI and drivers review
14:28:46 <rosmaita> that's not on the agenda, i forgot to mention this in announcements
14:29:08 <rosmaita> the tl;dr is that as you can see, there are a bunch of FFEs to get through
14:29:25 <rosmaita> so the third-party CI check may be late
14:29:31 <rosmaita> but, you do not have to wait for me
14:29:46 <rosmaita> you can check the reliability and responsiveness of your CI and take appropriate action now
14:29:55 <jungleboyj> ++
14:30:13 <rosmaita> #link http://cinderstats.ivehearditbothways.com/cireport.txt
14:30:54 <rosmaita> also, i don't believe that any of the third party systems have added the tag so that gerrit will not clutter up the comments
14:31:08 <rosmaita> that will get you bonus brownie points if you do it
14:31:34 <rosmaita> i will dig up the link to my email explaining what i am talking about during open discussion
14:31:59 <rosmaita> #topic [SVF]: Fix mkvdisk volume name length issue
14:32:02 <rosmaita> this one is mine
14:32:32 <rosmaita> i guess the question here is how much freedom the third-party drivers should have with respect to their code
14:32:45 <rosmaita> #link https://review.opendev.org/c/openstack/cinder/+/790910/9/cinder/volume/drivers/ibm/storwize_svc/replication.py#159
14:32:49 <rosmaita> specifically, ^^
14:33:13 <rosmaita> you can read my comments in there, but i disagree with the approach
14:33:32 <rosmaita> but i don't know that a -2 is appropriate
14:35:00 <eharney> the concern is breaking users on upgrade?
14:36:02 <rosmaita> no, for this one, the problem is that the generated name is too long, so it's being shortened, but in a way that will probably give you clashing names, except if you are using a patched version of openstack
14:36:35 <rosmaita> so, technically, it fixes the bug, but in a way i personally find quite distasteful
14:36:38 <eharney> clashing names could easily cause a security or data loss problem
14:37:06 <jungleboyj> eharney:  Good point.
14:38:23 <rosmaita> ok, well, i don't want to hold up the meeting ... if i am being unreasonable, please leave a comment on the patch and i will reconsider
14:38:29 <rosmaita> thanks!
14:38:49 <rosmaita> #topic last legacy zuul job!!!
14:39:03 <rosmaita> tosky: that's you
14:39:12 <rosmaita> #link https://review.opendev.org/c/openstack/cinder/+/751579
14:40:10 <rosmaita> my last memory was that I +2d the patch, but apparently that was premature
14:41:47 <rosmaita> looks like it passed on the most recent patch
14:41:56 <rosmaita> (you have to look in the experimental section)
14:42:49 <rosmaita> it does 6 backend migrations
14:43:25 <tosky> sorry!
14:43:33 <tosky> too much multitask at this time of the day
14:43:43 <rosmaita> tosky: that's ok ... what was the most recent change?
14:43:48 <tosky> rosmaita: a rebase
14:43:54 <tosky> just like the last-but-one change
14:44:02 <rosmaita> oh, ok
14:44:17 <rosmaita> here's the job output if anyone is curious (as you all should be):
14:44:18 <tosky> as soon as it merges, I will backport to all "live" branches
14:44:19 <rosmaita> #link https://zuul.opendev.org/t/openstack/build/f87f36ff76c24ffbb7d420f4c6f20dd8
14:44:42 <rosmaita> it's either completely insane or insiduously clever, depending on your perspective
14:45:17 <tosky> but, unless you find something to change, please hurry up or I will have to keep rebasing every time a change in .zuul.yaml creates a merge conflict
14:45:27 <tosky> (or I will just end up ripping it out, but...)
14:46:02 <rosmaita> i think it's worth having around
14:46:16 <rosmaita> but everyone needs to remember that it has to be triggered manually
14:46:33 <rosmaita> but if you touch anything that might affect volume migrations, you should definitely run it
14:46:41 <tosky> or it can be moved to the main queue, but I wanted to port it first
14:46:45 <rosmaita> or if you are reviewing such a patch, you should trigger it
14:47:25 <rosmaita> it's faster than the regular tempest test job, so as long as it's stable, that shouldn't be a problem
14:47:33 <rosmaita> anything else?
14:48:35 <rosmaita> #topic open discussion
14:50:13 <zoharm> requesting reviews / merge of this brick patch: https://review.opendev.org/c/openstack/os-brick/+/806687 it fixes nvmeof volume attachments for multipath enabled compiled kernels. There are mutiple other connector fixes that were bundled into the large "nvmeof agent" change, but this fix is the most criticial, to allow folks to at least use this connector code on Ubuntu 20.04 without patching in out of tree code
14:52:00 <enriquetaso> I'd like to ask for reviews and re reviews on https://review.opendev.org/c/openstack/cinder/+/750782 :D
14:52:21 <enriquetaso> zoharm, I'll take a look
14:52:23 <rosmaita> found the email about  vendors adding the 'autogenerated:XXX' tag to their gerrit comments:
14:52:23 <rosmaita> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022733.html
14:52:45 <whoami-rajat> review request for a simple change, adds a debug log connection_info returned from driver https://review.opendev.org/c/openstack/cinder/+/803696
14:53:57 <fabiooliveira> review request for https://review.opendev.org/c/openstack/cinder/+/798198 -- CI is green now :)
14:54:22 <rosmaita> fabiooliveira: is that your FFE patch?
14:54:28 <fabiooliveira> yes
14:54:36 <rosmaita> ok, great
14:54:37 <fabiooliveira> its sfernand, actually
14:56:26 <rosmaita> ok, if there's nothing else to talk about, no sense hanging around
14:56:30 <rosmaita> thanks everyone!
14:56:36 <zoharm> <3
14:56:36 <whoami-rajat> thanks!
14:56:40 <jungleboyj> Thanks!
14:56:59 <fabiooliveira> :D
14:57:29 <rosmaita> #endmeeting