16:00:03 #startmeeting cinder 16:00:07 Meeting started Wed Oct 23 16:00:03 2019 UTC and is due to finish in 60 minutes. The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:11 The meeting name has been set to 'cinder' 16:00:11 #topic roll call 16:00:14 o/ 16:00:17 o/ 16:00:25 o/ 16:00:32 hey 16:00:33 rosmaita: hi there :-) 16:00:40 hello! 16:00:43 o/ 16:00:51 @! 16:00:51 <_pewp_> jungleboyj (◍˃̶ᗜ˂̶◍)ノ” 16:00:55 Hi 16:01:07 looks like a good turnout! 16:01:14 o/ 16:01:21 https://wiki.openstack.org/wiki/CinderMeetings needs an update (this is still how i find the etherpad half the time) 16:01:22 #link https://etherpad.openstack.org/p/cinder-ussuri-meetings 16:01:34 hi 16:01:36 i thought i had updated that 16:02:18 well, speaking of updates 16:02:22 #topic updates 16:02:33 er.. Ussuri is there. maybe i found a very old browser tab... 16:02:43 :) 16:02:57 just a few announcements 16:03:19 the final releases from stable/queens happen sometime between now and tomorrow 16:03:44 and then stable/queens goes into 'extended maintenance' status, which means no more releases, but we can backport fixes 16:03:58 Sounds good. 16:04:20 the idea is that some distros/packagers may want to do releases including new bugfixes, even if we (opensatck) aren't committed to doing it 16:04:44 also, we had talked about doing monthly releases from the stable branches 16:04:56 over the past half year, it's looking like every 2 months is fine 16:05:13 (and we can always do a release at any time if there's a critical/security bugfix) 16:05:34 extended maintenance ends up being pretty close to our driverfixes branches. 16:05:45 Sounds good to me on the stable release cadence. 16:06:05 yes, and on that note, here's a picture of what we've got open branch-wise: https://launchpad.net/cinder/+series 16:06:34 i don't have anything to say, other than it's a lot of open branches! 16:06:54 ok, two final things 16:06:54 mitaka is still "Supported" :) 16:07:24 yes, i wonder if we should think about unsupporting some of those 16:07:25 Is anything before Mitaka actually still hopen? 16:07:38 no, i think that's the earliest open branch 16:07:52 Ok. Maybe we should update that then. 16:07:56 I think because that's where we started the driverfixes thing. 16:08:02 smcginnis: right 16:08:13 I think it's been long enough. I'd like to get rid of M and N at least. 16:08:25 smcginnis: ++ 16:08:29 I think we could even decide to EOL ocata and maybe pike. 16:08:39 M, sure. N... i dunno 16:08:51 that's what i was going to ask, what do we need to do to EOL a branch? 16:09:02 Realistically, I don't think we will be paying much attention past queens. 16:09:48 rosmaita: We would need to make sure all open reviews are closed. Then propose a $series-eol tag to the branch. 16:10:05 i wonder if we should convert to driverfixes only for n and o ? 16:10:17 I think we may need to also ask infra to delete the stable/$series branch too, just to make it clear. 16:11:00 N is already eol, so i think it is already driverfixes only 16:11:04 I think we're better staying at -em than adding a driverfixes branch. It's more "understood" now. 16:11:55 smcginnis: ++ 16:12:07 eharney: you are right about N 16:12:10 Well, N isn't tagged eol and the status is still set as Supported in Launchpad. 16:12:29 there's a newton-eol tag in git.. 16:12:45 Ah, ok. 16:13:05 well, the supported status is just me, i left that so we could target bugs to the driverfixes branch 16:13:13 makes sense 16:14:38 so with o & p, we could eol or we could have a stable-maint driverfixes only policy for those branches 16:15:21 the drivers don't seem to change so much (not as much as cinder itself), so backports wouldn't be too bad for serious bugs 16:15:43 The tricky part with these is keeping tests going. 16:16:00 I think Mitaka and Newton might actually be effectively broken at this point. 16:16:01 that';s true 16:16:20 at least ocata would be good (it's harder to maintain, as it was caught in the early extended maintenance process and some zuul v3 jobs-related improvements can't be applied there) 16:16:34 we're still actively supporting OSP10 so we have an interest in Newton fixes... i'm not sure if anyone is going to consume fixes for ocata & pike or not 16:16:34 it would be good to switch it to unmaintained, I mean 16:16:55 Actually... 16:16:57 er s/OSP10/Newton/ 16:17:24 I think with driverfixes we said just pep8 and py27. That just requires tox based jobs, so I think we can drop any legacy jobs there. 16:17:43 Probably any extended maintenance branches if we really need to. 16:17:56 Makes sense. 16:18:00 ok, that's good to keep in mind 16:18:02 But good to keep broader testing around for the newer branches if/when we can. 16:18:50 so would it look weird if we kept driverfixes/newton but eol'd o and p? 16:19:14 Yeah 16:19:22 that's what i thought 16:20:01 Yeah, because we shouldn't be backporting to Newton without hitting O and P. Right? 16:20:12 Yeah. Even for just driver fixes. 16:20:18 that's questionable if we decide O&P don't exist anymore 16:20:33 If we do that, then N goes too. 16:21:02 what about moving o (and maybe p) to driverfix for now, and think more about it? 16:21:12 well, we'd be hitting all open branches if we skip o & p and backport to N 16:21:35 We can't drop newer ones and keep older ones. 16:21:59 Either we keep through to the older one we want, or we cut them off. 16:22:40 ok, but we could adopt the "driverfixes only" policy for them 16:23:13 Yes 16:23:39 i think what i'd like to do is circulate something on the ML [cinder][ops] and see what people are using 16:23:44 and we can make a decision at the ptg 16:24:09 basically, what tosky said 16:24:19 ++ 16:24:52 good segue to the next announcement 16:25:04 #link https://etherpad.openstack.org/p/cinder-ussuri-ptg-planning 16:25:08 ++ 16:25:24 i'll add possible eol to the etherpad 16:25:48 but if anyone has a topic they'd like to see addressed, please add it! 16:26:07 and it looks like i skipped something 16:26:24 i just wanted to mention the U community goals proposals, in case anyone has a strong feeling 16:26:34 #link https://etherpad.openstack.org/p/PVG-u-series-goals 16:27:09 There are mailing list threads looking for goal champions for some of these. If anyone really wants to work on any of that. 16:27:09 i think that's all, except a reminder about adding yourself to the courtesy ping list at the top of the agenda if you want a ping at meeting time 16:27:37 rosmaita: ++ The new ping list is rather small right now. 16:27:55 yeah, tbh, i was mentioning it mainly in case anyone saw a community goal that would be a real PITA for cinder! 16:28:23 #topic leftover file locks 16:28:30 geguileo: this is you 16:28:37 rosmaita: thanks 16:29:01 mostly I just wanted to confirm that everyone was onboard with the proposed solution in the ML 16:29:27 this is about how cinder ends up leaving a lot of lock files 16:29:37 even when they are no longer necessary 16:29:51 Sounded like you had most scenarios covered that we could cover. 16:30:01 that solution being, having cinder code selectively remove the more commonly leaked files? or cleaning it on node startup? 16:30:12 both 16:30:19 well, Cinder wouldn't clean them up on start 16:30:32 but like you say it would be on node startup 16:30:39 The safest thing to do is cleanup on startup. Right? 16:30:41 and that would be the responsibility of the deployment tool 16:30:55 jungleboyj: yeah, but not Cinder (in case we are sharing the location) 16:30:58 geguileo: ++ 16:31:12 so the idea is that the installer creates a service unit that cleans up the directory 16:31:20 and makes all openstack services depend on that one 16:31:30 that way there are no races between removal and services using them 16:31:40 uhm, would it work if you restart just one service? 16:31:42 and in cinder we do our best to do the clean 16:32:05 tosky: no, because systemd would not retrigger the other unit 16:32:24 for example, the cinder-volume service would depend on the remove-locks unit having run before 16:32:29 and since it run at the start of the node 16:32:36 there is no problem and won't be retriggered 16:33:01 #link http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010129.html 16:33:08 ^ that's the ML thread 16:33:24 and this is a wip patch for the Cinder side of things 16:33:35 #link https://review.opendev.org/#/c/689486/ 16:33:59 the cinder side basically uses oslo's lock removal feature to remove them when deleting volumes or snapshots 16:34:10 and if the create volume from source fails as well 16:34:45 so this is a dumb question, but why don't we stop using file locks and use etcd-backed-tooz all the time, not just for active-active? 16:35:00 that's slower 16:35:05 just the cinder patch will cover most of these files, right, even without the other cleanup? 16:35:07 and etcd is not a requirement to run cinder 16:35:18 ok 16:35:25 eharney: yes, it should, but not for existing files 16:35:51 that's not so bad since the main issue these cause is admins saying "why are all these files in here?" 16:35:51 so the cleanup on node start is kind of a failsafe 16:35:59 lol 16:36:19 in case we missed something it would be good to have the cleanup on start as well 16:36:25 yeah 16:36:51 but I think this patch would be a reasonable compromise 16:37:01 it may not fix everything, but at least is better than nothing XD 16:37:07 It would at least slow the future growth in the number of files. 16:37:13 yup 16:37:28 well, it's definitely better than fixing too much (and breaking something) 16:37:35 So, I agree that it is better than nothing. 16:37:36 I wanted to confirm that we all agreed on this solution 16:37:44 ok 16:37:55 it sounds good to me 16:37:57 then I'll write the unit tests and all that stuff 16:38:09 Thanks geguileo 16:38:13 it sounds good to me 16:38:26 geguileo: Sounds good. Thank you! 16:38:35 great, then that's all I had to say :-) 16:38:39 smcginnis: jungleboyj np 16:38:52 thanks, geguileo 16:38:56 np 16:39:09 #topic request to change weekly meeting time 16:39:30 :o 16:39:37 i pulled this from the PTG etherpad, since i think it needs discussion beyond people who will be in shanghai 16:39:44 *sad_trombone.wav* 16:39:59 the request is to move the meeting 1 to 2 hours earlier 16:40:03 That would make it worse for west coast folks. 16:40:29 But I'd be curious to see if we would actually get more participation from APAC. 16:40:35 right 16:40:41 we don't need to decide this now 16:40:49 but i wanted people to give it some thought 16:40:52 Who was it that requested this? 16:41:03 and also about how we would best decide 16:41:08 Liang Fang 16:41:37 Ok. Well, I am open to it if there is enough additional participation. 16:41:41 for Europe I think it would be probably better 16:42:09 other than hemna part-time, do we have any west coast US people these days? 16:42:23 I know other teams have done alternating times, but I'm honestly not a big fan of that. 16:42:24 abishop 16:42:25 woojay: 16:42:39 apologies to abishop, if forgot he moved 16:42:40 smcginnis: Yeah, that ends up being a mess. I hate to say it. 16:42:40 yes 16:42:54 oh, I didn't know abishop was west coast now. 16:43:02 for Latin America it would be better too. 16:43:23 I'm ok w/ earlier though. 16:43:27 rosmaita: Have you checked if the channel is open earlier? 16:43:29 yeah, we tried the alternating times with Glance a few years ago, and what happened was that everyone always had the week wrong 16:43:43 rosmaita: ++ 16:43:46 smcginnis: i wasn't worried about that, figured we could use the cinder channel if we have to 16:43:55 Or things had to be repeated twice. That was the way it was for Swift. 16:44:23 woojay: how much earlier could you comfortably go? 16:44:29 namely, 1 or 2 hours 16:45:04 I am more likely to have clashes because that is when China schedules meeting wtih me. :-) But since I am not running things that is less concerning. 16:45:09 i am guessing 1 because once daylight savings time is over, it will be 2 hours 16:45:27 2 hours no problem. 16:45:57 woojay: Is an early riser? 16:46:04 Reminder for everyone that the time shifts in two weeks if you are in the US. 16:46:13 my boys get up early... 8-) 16:46:18 and in 1 week for most of europe 16:46:31 And not in one of those enlightened sections that actually doesn't observe DST. :) 16:46:50 and next week if you are in Europe 16:47:05 Sunday it would appear. 16:47:23 ok, well i just wanted to float that ... sounds like at least for the people here today, it's possible 16:48:00 should i send out an email for comments? 16:48:04 Yeah. Could make it work. Do it on a trial basis maybe. 16:48:14 +1 16:48:29 rosmaita: an email for comments would be good 16:48:52 ok, i'll put out an email and figure that anyone violently opposed will respond 16:49:06 Ok. Sounds good. 16:49:07 #action rosmaita email about possibly changing weekly meeting time 16:49:41 #action rosmaita email about possible EOL of some branches 16:49:44 (before i forget) 16:49:53 #topic open discussion 16:50:00 rosmaita, et al: yeah I'm on US west coast, but work east coast hours so I'm OK if mtg moves 16:50:13 abishop: ty, good to know 16:50:32 Cool. 16:50:41 Oh, do you want to mention the Cinder Dinner? 16:50:49 sure 16:50:59 what day were we thinking? 16:51:08 Thursday I think? 16:51:18 There is talk of an RDO event Wednesday night now. 16:51:39 ok, we are going to plan to have a cinder team dinner in Shanghai 16:51:46 Wouldn't it break tradition if we didn't schedule our team dinner at the same time as a Red Hat company party? 16:51:57 :) 16:52:00 smcginnis: ++ 16:52:20 lol 16:52:26 we are still working on time/location, but expect around dinnertime and in Shanghai 16:52:34 * jungleboyj laughs 16:52:41 I will get Chinese Takeout and wish I was there 16:52:46 Hah 16:52:49 davee__: He he 16:52:56 davee__: ++ 16:53:01 I forgot to e-mail my co-workers yesterday for ideas. 16:53:04 I will do that now. 16:53:19 Maybe in exchange for moving the meeting earlier, Liang Fang could make a dinner reservation for us. :D 16:53:20 ok, we will keep the PTG etherpad updated 16:53:31 :-) 16:53:33 smcginnis: that is not a bad idea 16:53:39 smcginnis: No Quid Pro Quo ! 16:53:45 lol 16:53:51 Haha, was just going to say something like that jungleboyj ;) 16:54:07 what good is a quid if you don't have a quo? 16:54:35 https://gph.is/g/ZyPyOXb 16:54:47 also, you don't have to be at the PTG to attend, just need to be constructively interested in Cinder and in Shanghai 16:54:58 rosmaita: ++ 16:55:12 jungleboyj: i am not going to look, your gphs are always a time sink 16:55:17 rosmaita: ++ 16:55:23 Bwah ha ha! 16:55:37 anything else on anyone's mind? 16:56:06 that jungleboyj staged that for the giphy! 16:56:38 rosmaita: You are planning that I will do the project onboarding again? 16:57:04 jungleboyj: yes, i was, though i may be confusing that with the upstream institute 16:57:21 are we supposed to schedule project onboarding as part of PTG time? 16:57:23 It is the Cinder specific part of the Upstream Institute. 16:57:51 rosmaita: Yes, so I was going to plan to do that early on Thursday as I will be in TC meetings on Friday. 16:57:52 yes, then i am definitely counting on you, i don't arrive until late monday 16:58:20 rosmaita: But it does happen as part of the PTG. 16:58:42 let's talk about this real quick in the cinder channel after the meeting 16:58:49 rosmaita: ++ 16:59:03 final minute ... any last concerns? 16:59:40 ok, thanks everyone! see you next week 16:59:45 thanks everyone! 16:59:51 o/ 17:00:00 Thanks! Talk to you all later. 17:00:09 Thanks! 17:00:13 i lost my etherpad tab and forgot the end meeting thing 17:00:17 #endmeeting