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