14:00:49 #startmeeting cinder 14:00:50 Meeting started Wed Mar 25 14:00:49 2020 UTC and is due to finish in 60 minutes. The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:51 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:53 The meeting name has been set to 'cinder' 14:01:00 #link https://etherpad.openstack.org/p/cinder-ussuri-meetings 14:01:01 o/ 14:01:10 #topic roll call 14:01:12 Hi 14:01:16 hi 14:01:26 o/ 14:01:32 pretty good turnout 14:01:41 agenda looks short, but actually there is a lot to do 14:01:55 #topic announcements 14:01:59 o/ 14:02:03 hi 14:02:04 i hope everyone is coping adequately with the covid-19 pandemic 14:02:10 i came across this interesting post, advice on handling isolation from astronauts 14:02:17 #link https://www.space.com/astronaut-tips-for-handling-isolation-coronavirus.html 14:02:24 i'd been thinking that the big stressor to cope with is not being able to get out much 14:02:31 but there's also the fact that you are now stuck with the same people for 24 hours a day 14:02:38 which can become stressful even if they are the nicest people you know 14:02:45 :D 14:02:55 #topic announcements - Victoria PTG 14:03:02 it was announced shortly after last week's meething that the Victoria PTG will be virtual 14:03:09 so keep the dates open: 8-11 June 2020 14:03:16 exact format not yet known, sign up if you want to help plan: 14:03:23 #link https://etherpad.openstack.org/p/Virtual_PTG_Planning 14:03:31 and, of course, start thinking about topics for the cinder part: 14:03:37 #link https://etherpad.openstack.org/p/cinder-victoria-ptg-planning 14:03:49 on the plus side, we should get a pretty good turnout! 14:04:02 #topic announcements - devstack-plugin-open-cas-core 14:04:10 Liang Fang was added to the core team for the plugin this morning 14:04:16 other core members are cinder-core and devstack-core 14:04:23 congratulations, Liang! 14:04:25 thanks, I see +2 and -2 now 14:04:30 :) 14:04:33 use them wisely! 14:04:41 #topic announcements - upcoming deadlines 14:04:44 Congrats LiangFang 14:04:53 we are winding down the ussuri cycle, believe it or not 14:05:00 so here are some dates to keep in mind 14:05:06 next week (week of 30 March): 14:05:16 * ussuri os-brick release 14:05:23 week after that (week of 6 April): 14:05:25 Ah, here it is. 14:05:40 * ussuri cinderclient release 14:05:40 * ussuri milestone-3 release 14:05:40 * FEATURE FREEZE 14:05:57 jungleboyj: did you just find the room? 14:06:02 two weeks after that (week of 20 April): 14:06:10 * RC-1 14:06:17 so, lots of stuff coming up fast 14:06:21 I thought I had joined it already. Apparently not. :-( 14:06:33 #topic announcements - driver reviews 14:06:41 so, i am aware of some grumbling about the non-speediness of driver reviews 14:06:47 which is understandable 14:06:52 o/ 14:06:54 but i'd like to remind everyone about the OpenStack Credo: 14:07:00 Never swim alone. 14:07:08 (no, that's the Penguin Credo ... i think i have cabin fever) 14:07:14 The OpenStack Credo: if you want to get reviews, you need to do reviews. 14:07:15 hi 14:07:22 :) 14:07:23 from the previous discussion you can see that we *must* get os-brick reviews done and merged before the next cinder meeting 14:07:30 and python-cinderclient the week after that 14:07:36 remember that you don't *have* to be a cinder-core to do reviews 14:07:42 and you don't have to work for a vendor to review that vendor's patches 14:07:49 and if you work for a vendor, you probably have a good idea of what's needed in driver patches 14:07:56 is the release note clear? have any doc updates been included? do the unit tests make sense? are there unit tests? 14:08:03 and you don't have to have an opinion on everything in the patch (like if there's some weird python usage you're not familiar with) 14:08:10 just say what you did look at when leaving your vote on the patch 14:08:17 this can speed up the reviews for everyone 14:08:19 ++ 14:08:24 rosmaita, ++ 14:08:24 same deal with os-brick or cinderclient patches, you can review those too 14:08:33 here endeth the lesson 14:08:34 ++ 14:08:41 #topic stable branch releases 14:08:49 #link https://etherpad.openstack.org/p/cinder-releases-tracking 14:08:55 a few things to discuss here 14:09:11 and i am doing them in reverse order from that etherpad (did not plan ahead, i guess) 14:09:18 #topic stable branch releases - cinder-tempest-plugin 14:09:25 not branched, so release would be from master 14:09:30 there are 2 open reviews 14:09:37 would be good to get some more tests in 14:09:43 so this is a call to please review and we can release around M-3 14:09:51 #topic stable branch releases - cinderclient 14:10:00 nothing to do for the brick-cinderclient-ext 14:10:08 there were no open reviews for python-cinderclient, so it's ready for release 14:10:24 #topic stable branch releases - os-brick 14:10:32 train is ready (i think ... pay attention to this discussion!) 14:10:40 stein has one open review (but don't immediately rush off and vote on it yet) 14:10:49 #link https://review.opendev.org/#/c/713082/ 14:10:55 it's an optimization (which could be fixing a legitimate bug if we're getting bad timeouts or something like that, so i don't think it should be disqualified simply because it's an optimization) 14:11:09 we allowed the backport to train, but smcginnis left a comment on the train backport 14:11:21 "I'm actually a little concerned about backporting this since it is such a divergence from how things have been working. Plus we haven't really had much runtime on it is ussuri, so there's a risk that there will be some issue found with doing it this way that we aren't aware of yet." 14:11:29 "All that said, we can always revert this, and if it's already made it out in a stable release we can always blacklist that release and quickly get a new release out that goes back to the previous behavior. So I think there's a slight risk, but it could be a nice improvement to get out there." 14:11:43 which is a good point 14:11:46 so my questions for us here are (let me list all 4 questions first, then we can discuss) 14:11:50 Yeah, just a little worried getting that backported all the way until we have confidence that it works right. 14:11:58 (1) do we release 2.10.2 from stable/train containing the already merged fix? 14:11:58 (2) do we hold off on backporting the fix to stein? 14:11:58 (3) do we *deny* the backport to stein? 14:11:59 (4) and if so, do we revert it from train? 14:12:13 ok, here we go ... 14:12:13 (1) do we release 2.10.2 from containing the fix? 14:12:19 I think yes and keep an eye on it as smcginnis suggests 14:12:37 (i have been typing like a maniac, i will now be quiet for a minute) 14:12:57 so... the main reason i didn't vote on this patch yet is because i didn't get around to convincing myself it would have no ill effects 14:14:20 If we aren't sure ... Nothing is broken if we don't backport it. Right? 14:14:29 It just is slower. 14:14:39 does anyone here know that this issue is causing problems in someone's current production, or if someone knows that an operator has already done a local backport and is running with this change already? 14:15:01 it was affecting one of our customers iirc 14:15:04 jungleboyj: i'm not sure if it's "just" an optimization or whether its causing timeouts 14:15:14 Ok. 14:15:35 some kind of scaling issue on large setups, i'd have to go find the details again 14:15:49 ok, so we do have evidence that the issue is a bug 14:16:18 yeah, if it only shows up at scale, it will be hard to see what this does 14:17:38 On the surface, it looks like a more reasonable way to do things. 14:17:59 Just we've been doing it the other way so long that it's an understood and well worn path. 14:18:02 This isn't yet. 14:18:06 exactly 14:18:53 so, it's already in stable/train ... should we release and see what happens? 14:19:12 i would think so 14:19:12 i just wonder if we'll get any feedback 14:19:43 ok, so (1): release from train including the fix 14:20:06 so, (2) hold off on backporting to stein for now? 14:20:07 It looks like it should be safe . We only will know if it causes issues by releasing it. :-) 14:20:25 jungleboyj: true enough 14:20:41 Chicken and egg. :-) 14:20:50 I think that's a good plan. I'm fine getting it in stein once we've had at least some real world run time to know it's not going to break something that isn't exactly configured like our gate images. 14:20:58 i'll look over it and see if moving away from a process call to a read opens up a window for races etc that wasn't there before 14:21:10 eharney: that would be great 14:21:48 worth noting that this affects both regular nfs and netapp nfs, too 14:22:08 ok, so it sounds like we don't deny it to stein yet, just don't include it in the release from stein this week 14:22:40 I am ok with that plan. 14:22:55 eharney: good point, maybe someone from netapp can also take a look 14:23:03 (hint, hint) 14:23:21 ok, sounds like we are all set there 14:23:30 #topic stable branch releases - cinderlib 14:23:38 this one is easy, there are no unreleased changes or open reviews on stable/train 14:23:41 :) 14:23:49 #topic stable branch releases - cinder 14:23:57 ok, last stable deliverable 14:24:05 stable/stein looks ready to go ... maybe (i will explain in a minute) 14:24:14 stable/train has one open review that i'd like to see merged, it fixes a segfault problem with the RBD driver 14:24:21 #link https://review.opendev.org/#/c/714151/ 14:24:27 it has one +2 atm 14:24:36 you'd think people would be screaming about a segfault problem, but it only happens during exception handling in a conditional branch controlled by a config setting 14:24:44 that's probably why you haven't heard about it 14:24:52 anyway, you can probably guess what i meant by stein was ready ... maybe 14:25:00 i think we should backport the change to stein after it is approved for train 14:25:07 and then release from stable/stein 14:25:13 but i am open to other opinions 14:25:47 That seems like a bug in the library that should get fixed. 14:25:58 and what about this (new) one? Would it be worth to have it in train, or (if it's merged in master and backported) should wait for the next release? https://review.opendev.org/#/c/711906/ 14:26:05 yes, eharney was saying that too 14:26:12 i tend to agree, but the general situation for is that if you do things that python-rbd doesn't want you to do, it just breaks :/ 14:26:20 and i think that isn't going to change in the near term 14:26:24 https://review.opendev.org/#/c/714151 fix actually seems opposite of the commit message description. 14:26:51 It says it is closed too soon, but then it code change closes it sooner/ 14:27:04 well, it takes the close out of the finally 14:27:17 Anyway, I don't need to understand it as long as it fixes things. :) 14:27:29 :-) 14:27:39 it gets closed sooner when there's an exception 14:27:52 (i spent a lot of time looking at this one) 14:27:52 Yeah, but it says that's the problem. 14:28:37 yeah, the problem is later, if you have to flatten the volume and get an exception there 14:28:41 then we try to clean up 14:28:53 but the source volume is already closed because of that "finally" at the top 14:29:14 I don't see how this improves that situation, but that's OK. We can move along. 14:29:25 ok 14:29:47 smcginnis: part of the problem is that the logic in there is pretty non-optimal 14:30:16 but the good news is that all this is handled on the rbd backend after the jewell release 14:30:30 so we can refactor that entire thing down to like 4 lines 14:31:20 ok, i lost track of where we are ... 14:31:47 let's leave this at please look at https://review.opendev.org/#/c/714151 14:32:13 if it is approved in the next few days, i'll propose a backport to stein 14:32:20 Should I remove my +W then? 14:32:33 it's approved as i see 14:32:34 only if you aren't sure about it! 14:32:49 ok, when i looked before the meeting it was still open 14:33:18 I changed it to just a +2 so those who have concerns can vote. 14:33:32 ok, sounds good 14:33:46 let's leave it open for 24 hours 14:33:58 so if you have concerns or general interest in the rbd driver please look 14:34:20 we aren't really on a deadline for the stable branch releases anyway 14:34:21 ok 14:34:30 i ignored tosky's suggestion 14:34:39 let's look at it 14:34:49 #link https://review.opendev.org/#/c/711906/ 14:35:35 that hasn't even made it into master yet 14:36:08 i'm a little concerned about this one, would like to dig into it more 14:36:17 i think we can wait for next release 14:36:24 Yep 14:36:27 ++ 14:36:42 ok, thanks ... and that's all for the stable branch releases! 14:36:45 ack, thanks; just wanted to asses its importance 14:36:54 we also need to more generally document some notes around all this volume renaming on migration i think -- it's bit us in a few different drivers 14:37:19 yeah, i think i have already seen a patch for a different driver on this same issue 14:37:26 #topic ussuri os-brick release 14:37:34 we have to release ussuri os-brick next week 14:37:45 this is what's been proposed: 14:37:46 https://review.opendev.org/#/q/status:open+project:openstack/os-brick+branch:master 14:38:14 a lot of WIP and -Ws in that list 14:38:31 Yeah. 14:39:17 And unaddressed -1's. 14:39:25 yes, that too 14:39:56 so, if there is anything urgent, please say so now, or on the ML in the next day or so 14:39:58 geguileo: You hace a couple interesting ones in there. Should we get those updated and try to get them in ussuri? 14:40:02 *have 14:40:30 let me check... 14:41:43 smcginnis: I think https://review.opendev.org/#/c/695144/ is an interesing one 14:42:19 smcginnis: iirc the FQDN one is less important and probably harder to fix 14:42:57 geguileo: Want to remove your -W? 14:43:00 rosmaita: after os-brick be released next week, will the remaining patches be reviewed in the following weeks or monthes? thanks 14:43:09 smcginnis: I should test it first... 14:43:25 I'll test it this week 14:43:34 geguileo: Thanks! 14:43:41 LiangFang: what will happen is that we will create a stable/ussuri branch for os-brick, and work can continue in master 14:43:41 np 14:44:04 rosmaita: thanks 14:44:05 so normal review turnaround :) 14:44:45 geguileo: great, thank you 14:44:54 rosmaita: that would means the feature would go to V release, right? 14:45:05 LiangFang: yes, that's correct 14:45:09 OK 14:46:12 moving along, then 14:46:29 #topic Added tempest tests to zuul for devstack-plugin-open-cas 14:46:39 #link https://review.opendev.org/#/c/713772/ 14:46:54 I have added the tempest test to zuul 14:47:12 I take a look of the job log, open-cas installed correctly 14:47:40 and I have removed debug info from code 14:47:46 uhm, I guess you can drop the -py3 suffix from the job name at this point 14:47:58 it's not like we are going to have a py2 job ever 14:47:59 ok 14:48:09 tosky: but not from the parent job? 14:48:22 line 3 in .zuul.yaml 14:49:20 that's tricky; as far as I remember, tempest-full should be py3 based nowadays; it may have been a problem if the new jobs were used in a branch < ussuri 14:50:15 ok, so i guess we leave it in the parent job name and let qa team make a mass proposal at some point to correct it in every project 14:50:30 but we can remove -py3 from our defined job 14:50:36 I suspect that's not going to happen, so let's fix at least our job 14:50:38 yep 14:51:02 ok 14:51:07 tosky: why don't you leave a comment on the review (if you haven't already) 14:51:18 doing it 14:51:22 great 14:51:42 I just added that comment. 14:51:47 Eric has some comments too. 14:52:14 ok, so at this point, the tempest jobs run with open-cas installed but not actually used 14:52:31 but that puts us in a good position as the other changes are made 14:52:52 LiangFang: anything else? 14:53:07 eharney: ERROR_ON_CLONE: false 14:53:45 this is because devstack will fail to git clone .../open-cas-linux repo if don't add this line 14:54:18 LiangFang: then something else should be changed 14:54:23 you shouldn't need that 14:54:26 that sounds odd 14:55:07 tosky: yes, seems odd, I don't seen ceph plugin have this line 14:55:22 but ceph plugin works 14:55:25 LiangFang: I will recheck the last build without that change, but I believe we should remove it before merging 14:55:35 ok, let's try to figure that out on the review 14:55:40 yep 14:55:45 #topic open discussion 14:56:09 anyone ... now's your chance 14:57:02 anyone who came in late, be sure to read my rant about reviewing during the "updates" part of the meeting 14:57:14 :D 14:57:14 :-) 14:57:20 just a zuul v3 reminder: even though this review leaves out one legacy job, it's still an improvement, and it would be nice to have it merged before branching ussuri: https://review.opendev.org/#/c/671945/ 14:57:54 yeah we should probably get that in 14:58:00 agree 14:58:02 +1 14:58:05 tosky: thanks for the reminder 14:58:14 #link https://review.opendev.org/#/c/671945/ 14:58:31 let's try to hit M-3 with that 14:58:49 hemna: If you joined late, please take a look at os-brick patches that are outstanding. :-) 14:58:58 it's should also be backportable, just in case 14:59:00 jungleboyj will do 14:59:06 hemna: Thank you sir. 15:00:11 hemna: especially https://review.opendev.org/#/c/706780/ 15:00:25 touches some code you've worked on 15:00:43 i think that one still needs some tweaking 15:00:51 cool, looks like it needs some work still 15:00:55 yes 15:00:58 and we are out of time 15:01:08 ok, thanks everyone 15:01:09 :-) 15:01:16 #endmeeting