16:00:09 #startmeeting Cinder 16:00:10 Meeting started Wed Feb 17 16:00:09 2016 UTC and is due to finish in 60 minutes. The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:14 The meeting name has been set to 'cinder' 16:00:16 Howdy 16:00:17 hello 16:00:19 hi 16:00:20 .o/ 16:00:21 hi 16:00:22 o/ 16:00:23 hello 16:00:24 hi 16:00:24 hi 16:00:24 o/ 16:00:25 o/ 16:00:27 hey 16:00:28 hi 16:00:30 Hi 16:00:30 hello 16:00:31 hi 16:00:32 hi 16:00:33 hi 16:00:37 hi 16:00:44 hi 16:00:46 #topic Release Status 16:00:55 hi 16:00:57 #link http://releases.openstack.org/mitaka/schedule.html Mitaka release schedule 16:01:32 Hmm, bot not working? Oh well. 16:01:40 Coming up on some deadlines. 16:01:49 bot doesn't respond to #link 16:01:49 We need to get os-brick cut for a final Mitaka release. 16:01:51 hello :) 16:01:59 bswartz: My topic didn't change. 16:02:01 oh nm 16:02:04 Hello! 16:02:04 that's weird 16:02:09 smcginnis: when are you going to do it? 16:02:12 Hi 16:02:27 bswartz: Lots of freenode reboots last night. Maybe didn't get reestablished. 16:02:41 e0ne: I would like to cut os-brick as soon as possible. 16:02:55 I think there is just one more we were waiting for. 16:03:14 diablo_rojo: hemnafk Do you guys have patches left? 16:03:14 Which one? 16:03:17 o/ 16:03:31 jungleboyj: Both my mine have been merged. 16:03:32 patrickeast_: You expect me to be prepared for this? :) 16:03:44 Haha 16:03:47 :) 16:03:49 patrickeast_: Such high expectations. ;-) 16:03:53 patrickeast_: I believe this was the last one: https://review.openstack.org/280817 16:04:21 smcginnis: As far as I know, that is the last important one to get in 16:04:35 But final client deadline and overall feature freeze is coming up quick. Basically until the end of the month. 16:04:46 Then it's bug fixes only. 16:04:54 So please be prepared. No surprises. 16:05:13 replv2.1 is a bug fix, right? 16:05:24 It seems so 16:05:29 smcginnis: I would like to get my python-brick-cinderclient-ext's patch merged in Mitaka 16:05:37 Swanson: Good question. For our purposes, yes. 16:05:40 Swanson: Yes I believe so. 16:05:45 smcginnis: attach/detach features. I'll update the patch later tonight 16:05:47 e0ne: Oh good, I was going to ask you about that. 16:05:55 e0ne: Thanks! 16:06:13 e0ne: I believe that falls under "client libraries", so we have a little time on that one. 16:06:17 But the sooner the better. 16:06:29 smcginnis: I was waiting for hemna to get privsep in os-birck, but looks like I have to use oslo.rootwrap in Mitaka :( 16:06:37 yah :( 16:06:45 #info Bug count: Cinder - 520 open bugs, Python-cinderclient - 42 open bugs, OS-Brick - 11 open bugs 16:06:47 privsep just isn't stable just yet 16:07:00 e0ne: Yeah, I don't think privsep is going to happen, unfortunately. 16:07:07 For now I mean. 16:07:12 We definitely need to get there. 16:07:14 agree 16:07:14 o/ 16:07:20 hemna: That's correct, right? 16:07:34 yah for now 16:07:44 I'm still seeing nova lock up during attach 16:08:07 OK, another bigger agenda today, so let's get moving and circle back on things if we have time at the end. 16:08:14 #topic RPC version bumping 16:08:17 dulek: Hey 16:08:17 hemna: I didn't have time to take a look on it closer :( 16:08:17 Hi! 16:08:26 e0ne, it's ok gus is working on it 16:08:36 it's something with the internals of the lib itself 16:08:41 I couldn't track it down 16:08:50 Basically to drop all of our backward compatbility stuff in managers and rpcapis we should bump major RPC versions. 16:09:02 We have this stuff in volume and scheduler APIs. 16:09:05 dulek: Prior to the M cut? 16:09:12 smcginnis: Just before it. 16:09:28 OK, gotcha. 16:09:28 All the resources of Nova's guidelines in this matter are in agenda. 16:09:32 #link https://review.openstack.org/#/c/281307/ 16:09:32 dulek: is it required for rolling upgrades? 16:09:38 #link https://review.openstack.org/#/c/281317/ 16:09:50 These are my PoC patches to show you how it looks like. 16:10:06 It's a little messy unfortunately, but goes away as soon as Mitaka is cut. 16:10:28 e0ne: Not exactly - we can stay on 1.0, but then technically we should keep to have backward compat shims. 16:10:36 dulek: So put that in, make the M cut, then right away in Newton clean it up? 16:10:36 s/1.0/1.x 16:10:49 That's how it works in Nova. 16:10:53 So the only question is: 16:11:18 Do we want to do that in M, or we're keeping our backward compat code through N and do that in N? 16:11:43 You mean O? 16:12:19 Well, yeah, that would mean dropping 1.x backward compat code in O. 16:12:41 DuncanT: Had the opinion we should do this in Mitaka. 16:12:52 * jungleboyj is confused. 16:12:54 This have the advantage of not accumulating tech debt. 16:12:57 jungleboyj: ditto 16:13:24 So, the version you have now has the compat shims in, right? 16:13:26 jgriffith, jungleboyj: Anything specific I can try to explain better? 16:13:46 dulek: I'm reading your link on agenda 16:13:51 dulek: So, that can go away as soon as we cut Mitaka as we start Newton development? 16:14:28 jungleboyj: Yeah, but technically we should bump major version to indicate that 2.0 manager doesn't understand 1.x calls. 16:14:34 apparrantly jgriffith is Guest2815 :) 16:14:54 * DuncanT arrives late, sorry 16:14:54 dulek: Starting with Mitaka? 16:15:01 dulek: so the write up there makes sense... and I kinda get it. I was a little confused with all the "do this in m, n o" talk 16:15:07 * jungleboyj yells DUNCAN!!!! 16:15:19 Guest2815: Multiple personalities? :) 16:15:42 dulek: It would be nice to get this through sooner. 16:16:06 smcginnis: yeah I know right :) 16:16:06 jungleboyj: Yes. Released version would actually need to support both 1.x and 2.0 to support rolling upgrades, but just for a moment. 16:16:19 dulek: It's some ugliness we'll have to deal with at some point, right? Might as well do it and then get things cleaner. 16:16:26 Then the 1.x support is removed to clean things up. 16:16:28 This is complicated that we have two upgrade scenarios - relaese to relaese and continous deployment from master. 16:16:31 dulek: given that we don't do rolling upgrades anyway is that an issue? 16:16:42 dulek: in other words can we just rip the band-aid and upgrade? 16:17:09 dulek: Or do I still have no idea what I'm talking about :) 16:17:14 jgriffith: I don't get the band-aid wording, but well, with my RPC compatibility layer patches we seem to support rolling upgrades. 16:17:23 dulek: Rolling upgrades are working now, right? 16:17:35 I wouldn't say it's bulletproof as we don't have a CI, but they should be working. :) 16:17:40 dulek: :) 16:17:48 jgriffith: Rolling upgrades mostly work now, we should get in the habit of not intentionally breaking them ASAP 16:17:58 DuncanT: +1 :) 16:18:07 won't the 4-byte UTF-8 fix (if we do it) break rolling upgrades/ 16:18:22 DuncanT: fair... I didn't know they were in a workable state to go from say M-->N 16:18:23 bswartz: I'm not holding up anything on that. :/ 16:18:36 bswartz: It should bee possible to do that without breaking. 16:18:38 bswartz: I still have my doubts about that. 16:18:51 I'm just saying -- get that fix in BEFORE rolling upgrades are supported so that you don't have to break them 16:18:59 jgriffith: We're in workable state in going L->M. :) 16:19:03 bswartz: Fair 16:19:06 oh I stand corrected -- thanks dulek 16:19:18 dulek: excellent... see, I didn't know what I was talking about :) 16:19:26 :P 16:19:46 bswartz: We need to figure out how to do things like that during rolling upgrade... hard work but should be solvable, and the solution can be reused 16:20:18 Okay, so seems like there's consensus on "do it"? Please review my patches then, we need them ready before the release comes. I'll keep them updated. 16:20:26 So are we in agreement that we should get this in at the end of M? 16:20:32 DuncanT: I'll work with sheel and jgregor to solve that. 16:20:40 smcginnis: +1 16:20:48 +1 16:20:54 smcginnis: I'm mixed, but honestly I don't see much value in dragging it out another 6 months 16:20:59 dulek: Affirmitive 16:20:59 smcginnis: It sounds like it is the right time to do it though there is some risk. 16:21:08 jgriffith: ++ 16:21:18 OK, cool. 16:21:28 dulek: Anything else on this one before we move on? 16:21:37 Nope, I'm fine. 16:21:44 #topic RequestSpec and FilterProperties objects patches 16:21:49 dulek: Well, still you. ;) 16:21:50 Still me though. ;) 16:22:06 #link https://review.openstack.org/#/q/status:open+project:openstack/cinder+topic:bp/cinder-objects+owner:%22Michal+Dulko+%253Cmichal.dulko%2540intel.com%253E%22 object patches 16:22:31 Okay, you've certainly seen these patches, I have a feeling that it's a little late in the release to merge them? 16:23:01 dulek: Yeah, that's kind of what I'm thinking. 16:23:13 A little too much code churn for comfort at this point I'm afraid. 16:23:24 They don't seem to fix any immediate issues, do they? 16:23:32 They're meant to detect changes in RPC payload, but if something happened without them, then we're incompatible anyway. 16:23:54 dulek: So they're future protection, right? 16:23:54 DuncanT: No, more like detection of possible issues. 16:24:14 smcginnis: Mostly yes. There's only one small possible problem I'm aware of that these can help with now. 16:24:30 (we've changed what flies over in RequestSpec in retype) 16:24:54 Anyone have a different view? 16:25:11 dulek: So it sounds like it is something that needs to bake more before being pulled in? 16:25:50 jungleboyj: More like risk is higher than gain here (from my perspective). 16:25:52 dulek: I think it's ready... just a question of risk and timing 16:26:10 The fact that we were unable to merge these earlier means that our rolling upgrades support in this release I would call "tech preview". 16:26:20 dulek: So in your opinion they should wait? 16:26:22 dulek: based on what you're saying doesn't seem like there's real signficant draw-back to waiting 16:26:35 so let's be prudent and do that 16:26:41 dulek: I'll make sure to state that (or at least try to) when asked. 16:26:48 jgriffith: +1 16:27:08 dulek: Sounds like something to wait on then. Are we saying that rolling upgrades are just tech-preview now? 16:27:11 And "tech preview" here would mean - play with it, give us a lot of feedback, but please don't blame us if something breaks if used in production. 16:27:24 How about that statement? 16:27:29 dulek: I like it. 16:27:40 dulek: +1 16:27:40 dulek: Yeah, I think it would be good to say that. 16:27:58 I think rolling upgrades are a space where we are going to have to have people try it to get it all baked out. 16:28:35 jungleboyj: I agree. The more runtime and different environments the better. We need that before we really have confidence that we didn't miss something. 16:28:35 And looking in the future - my plans are to get us a proper partial-grenade CI working to make sure we're confident in upgrading M->N. 16:28:49 dulek: That will be huge! 16:29:00 dulek: nice 16:29:23 dulek: Anything else? 16:29:40 Okay, so I'm not taking any more time. I'll bug you for at least to more patches to get into Mitaka offline. :) 16:29:59 dulek: Thank you for all your work on that. It's very much appreciated. 16:30:09 (don't worry, smaller ones :)) 16:30:09 smcginnis: Agreed. 16:30:15 dulek: And don't get hit by a bus until it's all done. ;D 16:30:35 smcginnis: Trying to be careful. :) 16:30:41 #topic Third Party CI recheck triggers 16:30:44 :) 16:30:56 So this has been a point of some confusion. 16:31:00 dulek: Thanks. 16:31:22 Originally the official page said to use the pattern "recheck CI_NAME" for rechecking third party CI. 16:31:30 But that pattern would also recheck Jenkins. 16:31:47 Which is definitely not wanted when things are busy and you just need one CI to rerun. 16:31:52 They've since removed that from the page. 16:31:58 smcginnis: it should be infra's bug 16:32:17 In the mean time, I've tried to direct folks to put their recheck patterns at the bottom of their page here: 16:32:23 #link https://wiki.openstack.org/wiki/ThirdPartySystems Third Party CI list 16:32:25 e0ne: it's not really a bug 16:32:31 Most but not all have done that. 16:32:46 It's still a bit of a pain to have to remember the link and look it up though. 16:32:53 smcginnis: so maybe you're getting to it, but I'll ask again since I don't think the folks that objected last time are here :) 16:33:05 * jgriffith pauses... and waits for it 16:33:06 I believe jgriffith proposed ... Go ahead./ :) 16:33:11 jgriffith: I mean, we need to have 2 options: recheck upstreaam CI, 3-rd party CI and all CIs 16:33:26 smcginnis: nope, you're on it... I'm kicking back with my cup-o-Joe 16:33:33 jgriffith: Haha, OK. 16:33:46 e0ne: The problem is "recheck *" has to work for Jenkins. 16:33:54 jgriffith: And slice of cheesecake? 16:34:04 You guys sure know how to create suspense.... 16:34:14 So if we just all agree to use "recheck-CI_NAME" then the extra - will prevent Jenkins from going. 16:34:33 So "recheck" can get all, and "recheck-" can get individual ones. 16:34:36 recheck-DIEDIEDIE will also be fine? 16:34:46 dulek: Absolutely! :) 16:34:50 scottda: I know you hemna and Ramey had some strong objections to that... but I think it's a good idea 16:34:55 smcginnis: sounds good to me 16:34:58 smcginnis: I would love consistency!!!!! 16:35:02 objecting to what exactly? 16:35:05 dulek: is it for HP CI? ;) 16:35:07 +1 for consistency 16:35:12 jgriffith: I had no objections. Ship it. 16:35:16 jungleboyj: Yeah, consistency would be a nice improvement here. :) 16:35:20 good enough for me 16:35:27 * jgriffith doesn't look a gift horse in the mouth 16:35:39 #action CI maintainers update triggers to go on "recheck-CI_NAME" 16:35:42 hemna: why did you not like that idea? 16:35:51 So you can still support other patterns. 16:35:54 I don't remember objecting to anything 16:35:56 diablo_rojo: if he doesn't remember, don't remind him :) 16:36:02 jgriffith: +1 :D 16:36:09 But if we can all at least support recheck-NAME then that would help a lot. 16:36:15 jgriffith: +1 16:36:25 I'm not sure we can use the word 'recheck' though in the string 16:36:34 hemna: Why not? 16:36:37 And I will update the wiki with this direction so new folks know as well. 16:36:41 sry was afk for a few 16:36:49 I think it will get picked up by jenkins recheck automatically? 16:36:51 asselin 16:36:52 hemna: If I remember right, the regex they use looks for space after. 16:36:53 hemna: is right, any string starting with recheck will trigger jenkins too 16:36:54 afaik 16:36:54 smcginnis: yeah, they can tell the old-timers then how's it supposed to go. 16:37:10 flip214: ;) 16:37:17 ive seen a bunch using the 'run CI_NAME' syntax, that might be safer 16:37:28 OK, I'll take an action to double check the recheck regex. 16:37:36 patrickeast_: we use that 16:37:40 patrickeast_: +1 16:37:58 #link http://git.openstack.org/cgit/openstack-infra/project-config/tree/dev/zuul/layout.yaml#n20 16:37:59 If it would still trigger Jenkins even with a - then we'll have to change. 'run CI_NAME' works for me. 16:38:06 I'm 100% for consistency that works 16:38:14 run-CI_NAME ? 16:38:21 smcginnis: ^^ here is regexp which infra uses 16:38:24 patrickeast_: +1 16:38:31 run CI-name 16:38:36 e0ne: OK, no checking for space after recheck. 16:38:41 patrickeast_: +1 16:38:50 So "run CI_NAME" it is? 16:38:52 patrickeast_: That works for me. Is clear. 16:38:55 patrickeast_: +1 16:38:57 smcginnis: +1 16:39:02 smcginnis: Yeah that seems safests 16:39:06 +1 on any working option 16:39:06 *safest 16:39:12 #action CI maintainers update triggers to go on "run CI_NAME" 16:39:14 e0ne: +1 16:39:27 *working but the *same* for all 3rd party CIs 16:39:27 OK, this is probably more than enough time spent on this. Next move on. 16:39:27 smcginnis: +1 16:39:30 good with me... I'll update sos now 16:39:42 #topic Removal of Cisco Fibre Channel Zone Manager Driver 16:39:46 smcginnis: and put it on CI wiki? 16:39:46 +1 16:39:53 e0ne: nice save 16:39:59 adrianofr_: I will get it on the Cinder wiki. 16:40:06 its actually 'run-CI NAME' ie. run-HPE Storage CI 16:40:08 #link https://review.openstack.org/#/c/278201/ Removal patch. 16:40:16 smcginnis: ok 16:40:34 Anyone from Cisco here? 16:40:45 kmartin: You are confusing things!!! 16:40:54 yumapath has been my contact for their ci 16:40:57 smcginnis: IMO, we're safe to remove it 16:41:03 dont see her online 16:41:06 we use 'run emc-vnx' 16:41:31 smcginnis: When was the last time their CI reported? 16:41:32 So we've tried IRC pings, direct email, we even tried to physically track someone down in Tokyo. 16:41:41 diablo_rojo: Never. 16:41:42 Oh, please let that become run dmc after the merger. 16:41:44 smcginnis: i've been working with them 16:41:45 diablo_rojo: They never set up one. 16:41:51 smcginnis: Good stalking. 16:41:52 patrickeast_: Me too. 16:41:53 smcginnis, it's been multiple releases that I've tried 16:42:06 patrickeast_: And they've said they were working on it for some time now. 16:42:07 I tried even in Vancouver to talk to my Cisco contacts 16:42:11 Swanson: :) 16:42:12 smcginnis: Well then. I think yanking it is fair. 16:42:12 Over a few releases now. 16:42:15 And still no CI. 16:42:15 from what i've heard last they have the hardware and are struggling with the openstackci setup 16:42:21 imo we remove it 16:42:25 and just let it back once the ci is up 16:42:33 it *should* be soonish 16:42:37 but may not be 16:42:47 So we should be consistent. We've certainly given them more leeway than we have for other backend drivers we've removed. 16:42:51 patrickeast_: Yeah, we could always revert the patch. 16:42:59 patrickeast_: Yeah I agree. They can get added back in Newton if they get their CI going 16:43:01 patrickeast: +1 16:43:03 Because it really does suck that we will only have one FCZM driver. 16:43:05 patrickeast_: They've had ages, pull it and re-merge, samea s we did for others 16:43:11 whatever you do, do it before feature freeze 16:43:13 smcginnis, we tried man 16:43:14 smcginnis: less is more 16:43:15 But we need vendors to back their drivers. 16:43:16 I don't know what else to do 16:43:20 thingee: ;) 16:43:36 smcginnis: Others have been removed while trying to get their systems set up. 16:43:45 no seriously. it was positive feedback we've receieved when we said these are the things in the release that we can say work 16:43:51 So I wanted to at least state all this officially here in the meting. 16:43:59 we should make sure though that we have enough testing time after we remove the cisco code 16:44:04 smcginnis: Removal might be motivating? 16:44:12 I will approve that patch, since there isn't anyone here defending why we shouldn't. 16:44:13 jungleboyj: it has in the past 16:44:26 thingee ... yep. Hate to say it ... 16:44:28 And they will need to work through the process to get it back in if they are willing to support it. 16:44:49 Good enough. Thanks! 16:44:52 #topic Multi-attach, determining when to call os-brick's connector.disconnect_volume 16:44:56 flip214: Hi 16:45:00 smcginnis: Are there other drivers at this point that are in the danger zone of being pulled? 16:45:15 smcginnis: thanks. 16:45:39 I just wanted to throw a question in, regarding the ML discussion "determining when to call os-brick's connector.disconnect_volume" 16:45:48 k 16:45:56 Are there plans to provide detach_consistencygroups et. al? 16:46:15 flip214, we don't do bulk attachment operations now 16:46:16 because DRBD *only* has a CG; when there are multiple volumes in one (in a DRBD resource) 16:46:19 wrt CGs 16:46:43 I'd need to do some kind of reference-counting, to avoid removing until *no* volumes should be there anymore. 16:46:47 flip214: no plan 16:47:00 so, for us it would make sense to have these calls... 16:47:01 flip214: That's an interesting point for that then. 16:47:23 having a CG that allows accessing individual volumes *only* sounds kind of strange anyway, TBH. 16:47:26 flip214: So you're saying with DRDB you _have_ to have reference counting in Cinder, otherwise no way to just remove one volume attachment? 16:47:50 apart from that point I'm done. thanks for listening, perhaps somebody tells me about the need to add that - 16:48:12 smcginnis: no, we don't need it in Cinder - the DRBD driver can do that as well... 16:48:23 but having something like that in cinder would certainly help. 16:48:25 flip214: OK, so you just mean in relation to CGs. 16:48:57 yeah, for CGs. 16:49:17 as long as a DRBD resource (== a CG) consists of one volume only, it won't matter, right. 16:50:10 OK, we can discuss detail in channel if needed. 16:50:12 flip214: Thanks! 16:50:17 thanks for the time and patience. 16:50:18 10 minutes reminder 16:50:21 #topic Reviewer sign-up for api-microversions 16:50:23 hi 16:50:24 scottda: Hey 16:50:29 #link https://etherpad.openstack.org/p/cinder-api-microversions 16:50:44 scottda: hi! when are you going to do a demo? 16:50:47 First, thanks patrickeast_ DuncanT e0ne for reviewing 16:50:55 It was hard to schedule a demo time that worked for everyone, so I'd rather schedule with any interested individuals. 16:51:01 scottda: and thanks you for fixind apache-related issues! 16:51:06 I can do pretty much anytime.. 16:51:19 scottda: I am interested :) 16:51:24 scottda: I'd like to see it tonight at 2AM. 16:51:40 2AM - which timezone? 16:51:41 I also want to point out that I copy-n-pasted tests/unit/api/v2 to /v3... 16:51:44 smcginnis: Only 1 am scottda time. 16:51:49 :) 16:51:54 which is a ridiculous amount of code duplication. 16:52:10 scottda: Can we just have those both go to a common code base? 16:52:18 scottda: Or is there a need to have them independent? 16:52:21 I intend to rip that out once I can use ddt (or something) to re-use the exisiting unit tests. IN another patch, I hope. 16:52:33 scottda: I'm not fun of copy-paste at all, but you plan sounds reasonable 16:52:33 smcginnis: +1 16:52:40 smcginnis: No real need, but I haven't had time to look at it and do it. 16:52:50 so that is an extra 5000 LOC!! 16:52:58 0_0 16:53:11 PIM 16:53:12 sorry about that, but adding the /v3 endpoint came late, and I think it's better to get this in for soak time first. 16:53:14 scottda: manila tackled this by using microversions in the unit tests. 16:53:17 (puke in mouth) 16:53:18 wha wha wha whaaaa 16:53:42 Ok, well I'll be working on that, but I don't want to hold up reviews with this. 16:54:03 scottda: I think I would actually feel better getting that combined first. But yeah, shouldn't hold up reviews. 16:54:36 I'll update the patch set ASAP when I can get those ripped out, but if people wait for that, we're coming up against feature freeze. 16:55:13 And it will be a lot of manual work to look at all the tests and make them work for both endpoints. So might take some time. 16:55:36 so basically review the code except ignore the v3 test cases for now since they'll get combined? 16:56:01 mc_nair: Yes, and they are dupes of v2, so I'm not sure how much reviewing is necessary anyway 16:56:13 scottda: Sounds good. 16:56:14 sounds good 16:56:28 #link https://github.com/scottdangelo/TestCinderAPImicroversions can help with testing 16:56:44 ping me in IRC for demo or other questions 16:56:56 But not after 9:00 PM MST (bedtime) 16:57:05 scottda: Yeah, I'd hate this to get held up on the tests. Thanks for being available for demos and questiosn. 16:57:19 scottda: Hey, you said _any_ time. :P 16:57:30 I lied 16:57:35 Hehe 16:57:45 #topic Open 16:57:48 2 minutes 16:57:49 Two last pieces of rolling upgrades: https://review.openstack.org/#/c/279039/ - fun patch to review to support resetting version pins on SIGHUP signal (to avoid service restarts) 16:57:51 Cross Project Updates 16:57:53 scottda: after 10pm is good gor you?:) 16:57:54 I said "pretty much anytime" 16:58:08 diablo_rojo: Anything quick? 16:58:11 https://review.openstack.org/#/c/279039/ - simple bugfix adding better backward compatibility. 16:58:38 The more complex common policy scenario is moving forward- basically they don't care that it seems too complicated- they wanted to make it like that so that it could work for everyone 16:58:45 #link https://review.openstack.org/#/c/279039/ Rolling upgrades patch 16:58:56 joy 16:59:03 #link https://review.openstack.org/#/c/263473 16:59:08 That's the second one, sorry. 16:59:13 dulek: Thanks! 16:59:19 smcginnis: Yep. So..Basically we just need to review it and make sure that it will cover all cases we need. 16:59:24 # link https://review.openstack.org/#/c/245629/ 16:59:47 I think there will be more discussion around it at the upcoming summit 16:59:47 diablo_rojo: Thanks. Anything else quick? 16:59:55 I'm sure. 17:00:05 Times up. Thanks everyone. 17:00:06 smcginnis: Lastly, the 4byte unicode char cp spec got good attention 17:00:33 smcginnis: Sounds like people are interested in moving forward with it once use cases get more clearly outlined 17:00:37 thats all 17:00:40 diablo_rojo: Thanks 17:00:43 #endmeeting