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