16:00:01 <smcginnis> #startmeeting Cinder
16:00:02 <openstack> Meeting started Wed Aug 31 16:00:01 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:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:05 <smcginnis> ping dulek duncant eharney geguileo winston-d e0ne jungleboyj jgriffith thingee smcginnis hemna xyang1 tbarron scottda erlon rhedlind jbernard _alastor_ bluex patrickeast dongwenjuan JaniceLee cFouts Thelo vivekd adrianofr mtanino yuriy_n17 karlamrhein diablo_rojo jay.xu jgregor baumann rajinir wilson-l reduxio wanghao thrawn01 chris_morrell stevemar watanabe.isao,tommylike.hu
16:00:06 <openstack> The meeting name has been set to 'cinder'
16:00:09 <geguileo> o/
16:00:10 <_alastor__> o/
16:00:14 <eharney> \o
16:00:16 <jgregor> Hola
16:00:16 <smcginnis> https://wiki.openstack.org/wiki/CinderMeetings#Next_Cinder_Team_meeting
16:00:17 <baumann> Hello
16:00:18 <tbarron> hi
16:00:19 <ntpttr> o/
16:00:20 <DuncanT> Hey
16:00:20 <scottda> hi
16:00:38 <mtanino> hi
16:00:44 <smcginnis> #topic Announcements
16:00:48 <swap-nil> hi
16:01:01 <smcginnis> Somehow we are already at N-3
16:01:07 <tommylikehu_> hi
16:01:08 <smcginnis> Time flies when you're having fun.
16:01:14 <smcginnis> #link https://releases.openstack.org/newton/schedule.html
16:01:20 <tommylikehu_> that's true
16:01:22 <diablo_rojo> Hello :)
16:01:24 <dulek> hi
16:01:29 <smcginnis> So this is feature freeze, soft string freeze, and client freeze.
16:01:38 <smcginnis> And requirements freeze.
16:01:39 <e0ne> hi
16:01:41 <Swanson> Hello
16:01:56 <dulek> Freezes are explained here: https://releases.openstack.org/newton/schedule.html
16:02:13 <geguileo> smcginnis: If somebody wants to request an FFE, when does it need to happen?
16:02:19 <diablo_rojo> Time flies when you're having fun.
16:02:20 <xyang1> hi
16:02:20 <smcginnis> So let's try to wrap up any outstanding items, then work on testing and making sure we're sending out something good.
16:02:27 <DuncanT> It's too warm here to freeze anything.
16:02:34 <smcginnis> geguileo: Begging and gifts of high quality coffee. :)
16:02:38 <geguileo> DuncanT: +1
16:02:54 <smcginnis> geguileo: I don't think we need a formal FFE process.
16:02:57 <geguileo> smcginnis: And is there a date limit?
16:02:59 <smcginnis> At least we haven't so far.
16:03:17 <geguileo> smcginnis: So anytime within the next 2 weeks would be OK?
16:03:17 <smcginnis> I've always left it at the discretion of the core team whether to allow anything in after the freeze.
16:03:27 <smcginnis> Based on the risk and importance.
16:03:32 <DuncanT> https://review.openstack.org/#/c/337061/ is been aproved for a while but is triggering jenkins bugs, I'd like to nominate it for FFE
16:03:33 <smcginnis> geguileo: Yeah, I think so.
16:03:45 <geguileo> smcginnis: Thanks
16:03:54 <smcginnis> Up until we tag RC I think is OK, if we are all OK with the risk of letting it in.
16:03:59 <jungleboyj> o/
16:04:01 <tommylikehu_> +1
16:04:08 <DuncanT> I'll chase the jenkins issue again
16:04:15 <smcginnis> DuncanT: I'm hoping this last recheck makes it through.
16:04:25 <e0ne> https://review.openstack.org/#/c/178262/ - can we get it in Newton?
16:04:26 <tommylikehu_> hoping so
16:04:41 <geguileo> DuncanT: +1
16:04:53 <geguileo> (not to the chase but to the FFE)
16:04:56 <e0ne> DuncanT: IMO, FFE is good if it caused by jenkins failure
16:05:00 <DuncanT> smcginnis: It is triggering a know bug in the ansible code according to infra folks.
16:05:11 <smcginnis> If anyone has any high priority items to make it in to Newton, please ping cores in #openstack-cinder and make sure we are aware of it.
16:05:19 <DuncanT> e0ne: I agree, just wanted to bring it up
16:05:23 <smcginnis> DuncanT: Oh? I hadn't heard of that one yet.
16:05:35 <smcginnis> e0ne: Yeah, I agree too.
16:06:05 <smcginnis> #topic Options for maintaining os-brick on stable branches
16:06:08 <smcginnis> geguileo: Hey
16:06:12 <geguileo> Hi!
16:06:14 <hemna> hey
16:06:35 <geguileo> Ok, we seem to be stuck in a situation where we cannot change stable releases os-brick versions
16:06:46 <smcginnis> hemna: Speaking of backward compatibility: https://review.openstack.org/#/c/363444/
16:06:56 <geguileo> On one hand we don't do backports, even though semver would allow it
16:07:00 <hemna> geguileo, why do we need to?  there is no upper constraint, just get the latest version
16:07:18 <smcginnis> I think that was always fine until we added privsep.
16:07:21 <geguileo> hemna: What do you mean there's no upper constraint?
16:07:32 <geguileo> hemna: There is an upper constraint in requirements project
16:07:42 <hemna> is there?
16:07:47 <geguileo> Yes
16:07:50 <hemna> bah
16:07:56 <dulek> Currently 1.5 I think.
16:08:00 <smcginnis> So we've never really had a need to do a stable library release before. But that doesn't mean we can't.
16:08:04 <geguileo> And if we try to bump it like here
16:08:06 <eharney> i don't see much reason not to do releases for older branches
16:08:07 <geguileo> https://review.openstack.org/360878
16:08:19 <e0ne> hemna: https://github.com/openstack/requirements/blob/stable/mitaka/upper-constraints.txt
16:08:21 <eharney> it will be nice for large fixes once master has moved forward a lot
16:08:23 <hemna> eharney, +1
16:08:29 <geguileo> We have problems because now we have privsep and we cannot do the version bump
16:08:37 <diablo_rojo> dulek, Yes I think you're right, 1.5
16:08:39 <e0ne> eharney: +1
16:08:42 <geguileo> eharney: +1
16:08:45 <tommylikehu_> +1
16:08:53 <smcginnis> Our policy isn't/wasn't that we absolutely will not do stable releases. Just we never had a need to before.
16:09:00 <geguileo> And we already have a bunch of patches in stable/liberty ahead of master
16:09:06 <hemna> so the issue is pulling a new version of brick that then installs privsep where it didn't exist previously?
16:09:08 <geguileo> https://github.com/openstack/os-brick/compare/0.5.0...stable/liberty
16:09:21 <DuncanT> Are we better dumping privsep as a failed experiment? Seems to have done way more harm than good, and has bought zero security improvements so far
16:09:33 <hemna> DuncanT, -1
16:09:36 <smcginnis> What? How is privsep a failed experiment?
16:09:37 <hemna> nah man, we can't
16:09:38 <eharney> i'm pretty sure we should continue with privsep
16:09:48 <geguileo> eharney: +1
16:09:53 <hemna> if we go that route, then the same argument will be made that brick is a failed experiment
16:09:54 <DuncanT> Why?
16:10:01 <jungleboyj> DuncanT: Agreed.  It has been a mess!
16:10:20 <DuncanT> hemna: Ah, ok, that's a point, though I would disagree with anybody saying that
16:10:20 <smcginnis> We've had some transition issues, but I don't think the premise is wrong.
16:10:32 <eharney> we are working on initial problems, but the good stuff like https://review.openstack.org/#/c/312498/ is still barely starting
16:10:33 <jungleboyj> hemna: I don't think they would say that.
16:10:38 <hemna> because nova won't tolerate going back to being tightly coupled with rootwrap filters and brick versions.
16:10:42 <smcginnis> eharney: +1
16:10:44 <diablo_rojo> jungleboyj, How much luck have you had talking to angus about the crap messages it throws?
16:10:47 <hemna> jungleboyj, that's what nova was saying previously
16:11:04 <hemna> jungleboyj, that unless we fixed the rootwrap filter nightmare that nova wanted to nuke using brick.
16:11:16 <jungleboyj> diablo_rojo: I have a todo to get him more info this week.
16:11:20 <hemna> it's the entire reason we moved to privsep in the first place
16:11:24 <jungleboyj> Hope to work on that tomorrow maybe.
16:11:45 <smcginnis> geguileo: I don't think with stable policy we can do much for liberty anymore. But we could certainly release a new Mitaka os-brick release.
16:11:46 <hemna> diablo_rojo, I have a defect filed against privsep that's been there for a while
16:11:49 <jungleboyj> hemna: Ah, ok.  So we did privsep to make Nova happy.
16:11:53 <hemna> zero response, and the bug hasn't been triaged
16:12:00 <eharney> jungleboyj: no
16:12:06 <geguileo> smcginnis: Yeah, I wasn't aiming at liberty really  XD
16:12:18 <DuncanT> eharney: Ah ha, I hadn't seen that, thanks, that is more encouraging
16:12:24 <jungleboyj> hemna: I have one for some issues where privsep just doesn't send any info back that had us wrapped around the axel for days.
16:12:24 <geguileo> smcginnis: I just think that we should allow backports to os-brick and do stable releases
16:12:26 <smcginnis> jungleboyj: To decouple the need to copy rootwrap files between nova and cinder and to be able to move forward with better more secure privileged code.
16:12:28 <hemna> jungleboyj, yes, because when new connectors are added or when a new command needs to be executed for a connector, you have to ship os-brick, and then put a patch against nova to add the new rootwrap filter.
16:12:28 <eharney> jungleboyj: there are pure-cinder things that privsep gives us, i dunno where that's coming from
16:12:31 <hemna> that's bad mmmkay
16:12:31 <diablo_rojo> hemna, *sigh*
16:12:39 <jungleboyj> hemna: For an issue that is easy to encounter.
16:12:44 <smcginnis> geguileo: I'm good with that.
16:12:55 <geguileo> smcginnis: Should we vote?
16:13:07 <smcginnis> geguileo: We can get some things backported, then raise the Mitaka upper constraints after we release a 1.4.1 or whatever version it would be.
16:13:11 <geguileo> smcginnis: Because in the end it'll be the stable maintainer who'll -2 those patches
16:13:13 <geguileo> XD
16:13:16 <hemna> geguileo, so what and how many are we needing to backport
16:13:20 <smcginnis> Just has to be minor backwards compatible bugfixes.
16:13:31 * jungleboyj nominates diablo_rojo to support privsep. ;-)
16:13:40 <geguileo> hemna: Well, there's the multipath patches
16:13:48 <geguileo> hemna: And there was another patch trying to get in
16:14:10 <hemna> well, I'm not sure those are really issues to be honest
16:14:12 <diablo_rojo> smcginnis, That sounds like a decent plan.
16:14:16 <geguileo> hemna: For now, I can think of 4 patches
16:14:20 <jungleboyj> hemna: eharney Ok, I will be honest that I haven't fully understood the privsep stuff.
16:14:28 <geguileo> smcginnis: +1
16:14:43 <jungleboyj> smcginnis: So we would add a 1.4.1 release for stable/mitaka to get wanted bug fixes in?
16:14:53 <hemna> ok, so I'm fine with backports because of privsep
16:14:54 <smcginnis> jungleboyj: Yep.
16:15:03 <jungleboyj> smcginnis: Ok, sounds good.
16:15:07 <smcginnis> So stable folks, let's look at backports for os-brick.
16:15:19 <smcginnis> If we're good with what's there we can request a new .1 release.
16:15:22 <geguileo> So we all agree that backporting in os-brick is allowed and that we'll do stable releases?
16:15:37 <smcginnis> Once that's released we can raise upper-constraints for stable/mitaka
16:15:40 <scottda> +1
16:15:42 <DuncanT> jungleboyj: See the patch Eric linked... it shows what privsep is *meant* to be like
16:15:48 <smcginnis> geguileo: Judiciously
16:15:50 <hemna> shit, so mitaka is stuck at 1.2.0
16:15:51 <hemna> fwiw
16:16:01 <hemna> so even if we did a 1.2.1 for a bugfix mitaka won't get it
16:16:05 <hemna> and 1.2.0 is ancient.
16:16:11 <hemna> https://github.com/openstack/requirements/blob/stable/mitaka/upper-constraints.txt#L202
16:16:15 <hemna> so I don't think we are solving anything.
16:16:19 <smcginnis> hemna: Why wouldn't it get a 1.2.1?
16:16:32 <hemna> it's upper constraint pegged at 1.2.0
16:16:45 <smcginnis> It certainly limits what we can get backported, but we can raise the upper constraint to 1.2.1 once we have a release.
16:16:58 <geguileo> hemna: Even if we end up not solving anything for Mitaka, maybe it will help for Newton once it's in stable
16:17:09 <jungleboyj> DuncanT: Will do.
16:17:10 <hemna> are we even allowed to touch those upper constraints for stable branches ?
16:17:25 <smcginnis> geguileo: Might not be an issue after this point. At least until another big thing like privsep comes along.
16:17:33 <eharney> you can bump them via the normal requirements process on its stable branch to some degree
16:17:35 <smcginnis> hemna: Yeah, we can if we need to.
16:17:42 <hemna> ok
16:17:47 <hemna> 1.2.0 is so damn old though
16:17:59 <smcginnis> hemna: No kidding. I was hoping it was newer than that.
16:18:04 <hemna> :(
16:18:10 <smcginnis> Didn't realize we had done so much since Mitaka freeze.
16:18:28 <hemna> anyway, mitaka is crazy out of date with brick then
16:18:31 <jungleboyj> hemna: and diablo_rojo were busy!
16:18:42 <hemna> so backporting fixes to mitaka isn't really reasonable
16:19:04 <hemna> jungleboyj, :)
16:19:11 <smcginnis> hemna: There's probably not too much we can actually backport, but maybe some bugfixes.
16:19:27 <hemna> but that also means that newton is the first release to use privsep
16:19:34 <smcginnis> Yep
16:19:48 <geguileo> hemna: I think some patches can actually be backported
16:19:50 <ntpttr> hemna: yeah actually another thing I ran into in rolling upgrades testing is that cinder-manage doesn't work after pulling down master
16:20:01 <hemna> smcginnis, there have been so many changes since the 1.1.X and 1.2.X versions that it's to many changes imho
16:20:07 <diablo_rojo> hemna, Is that a bad thing since we aren't really sure if it works now anyways?
16:20:07 <ntpttr> because of an import in brick that it can't find
16:20:27 <hemna> I completely rewrote the multipath code since 1.2.x
16:20:29 <eharney> this is a good example of something that would be backported to mitaka os-brick: https://review.openstack.org/#/c/341085/
16:20:32 <hemna> it would be tough
16:20:46 <dulek> ntpttr: Same happens when you install 1.5, which is in upper-constraints?
16:21:05 <hemna> eharney, the encryptors stuff didn't exist back then in brick
16:21:13 <geguileo> hemna: Yeah, maybe they can't be backported
16:21:16 <ntpttr> dulek: the only thing I tried to fix it, which worked, was to do 'pip install -U os-brick'
16:21:25 <geguileo> hemna: But at least we open the patch to do backports for the future
16:21:27 <ntpttr> that fixed the problem
16:21:34 <smcginnis> OK, we'll see if there is enough that can be backported and enough value to warrant a new stable release. If so we can do the release and bump the upper constraint.
16:21:34 <geguileo> hemna: If it doesn't work for Mitaka, bad luck  ;-)
16:21:38 <eharney> the executor stuff did...
16:21:39 <smcginnis> If not, oh well
16:21:46 <geguileo> smcginnis: +1
16:21:48 <diablo_rojo> Should we make a list of things to backport somewhere?
16:21:56 <hemna> geguileo, but I thought the reasoning behing allowing backports was because of privsep
16:22:02 <hemna> so.....
16:22:06 <hemna> Newton requires it
16:22:13 <geguileo> hemna: Not only because of privsep
16:22:13 <smcginnis> That's just the compelling reason at this point I think.
16:22:14 <eharney> diablo_rojo: we should track such things in launchpad, there are methods for doing that we've used for a long time already
16:22:22 <hemna> and prior to Newton the upper constraints is so old that backporting is going to be tough
16:22:28 <diablo_rojo> eharney, That works.
16:22:34 <geguileo> hemna: But we probably cannot go on bumping stable os-brick version unless we ensure backward compatibility
16:22:46 <geguileo> hemna: Which afaik we don't do
16:22:53 <smcginnis> Definitely we're not backporting privsep! :)
16:22:58 <hemna> I'm just saying I'm not seeing much value.  the backports to the 1.1.x and 1.2.x will be few and far between.
16:23:12 <smcginnis> hemna: Your probably right.
16:23:33 <eharney> 1.1.x and 1.2.x are both Newton... it will take a bit to see what we'd want to backport there?  (and we'd only backport to 1.2.x anyway, i think)
16:23:33 <diablo_rojo> Agreed
16:23:35 <hemna> geguileo, well for the most part that's been the idea.  any of my major work I've done in os-brick has always tried, if not required backwards compatibility
16:23:43 <hemna> and I was under the assumption that always had to be the case.
16:23:52 <jungleboyj> smcginnis: Oh come on, live dangerously.  ;-)
16:24:04 <eharney> if 1.1.x was created and obsoleted within newton then there isn't a reason to backport to it
16:24:20 <hemna> eharney, +1
16:24:22 <geguileo> hemna: It should be the case, but we don't try it as strictly as in cinder afaik
16:24:52 <jungleboyj> For future reference, though, this is important to agree upon.  Unfortunate that privsep complicates it in this case.
16:25:04 <hemna> geguileo, I've been enforcing it as much as possible in brick
16:25:04 <diablo_rojo> eharney +1
16:25:25 <hemna> which is one of the reasons that diablo_rojo and I had so much trouble getting the connector break out patch in
16:25:38 <eharney> to be sure on backward compatibility we need to define a policy and ensure we have gate jobs to back it up
16:25:40 <diablo_rojo> hemna yeah that was..quite the experience..
16:25:49 <eharney> i don't really know how close we are to that at this point
16:25:54 <e0ne> eharney: +1
16:26:16 <geguileo> eharney: +1
16:26:21 <smcginnis> eharney: I think the tests run when we try to bump the u-c are the enforcement there, but too little too late probably.
16:26:29 <eharney> i think today we were mostly trying to find our way toward a policy
16:26:31 <hemna> eharney, there are gate jobs that test ceph and lio
16:27:29 <smcginnis> I don't think our policy was ever that we wouldn't do a stable library release. Just that we never had need to before.
16:27:35 <hemna> so I guess what I'm asking is, does it make sense to allow an Ocata/Master fix backported to stable/Newton
16:27:39 <smcginnis> Onward and upward.
16:27:45 <hemna> since newton requires privsep
16:27:52 <hemna> and that's really the major limiting factor IMO
16:27:59 <eharney> i think it does because a lot of fixes will be independent of privsep (hopefully)
16:28:04 <jungleboyj> hemna: It sounds like that is what we are leaning towards.
16:28:10 <smcginnis> eharney: +1
16:28:13 <eharney> or be reworked to fit the old model as part of the backport process
16:28:21 <hemna> eharney, sure, but the reason we wanted to allow backports was because we couldn't force privsep on older releases
16:28:26 <jungleboyj> privsep just complicates it in this case.
16:28:29 <eharney> i don't think that was the reason...
16:28:34 <hemna> and now moving forward privsep will be there, just get the latest version.
16:28:35 <smcginnis> eharney: If we need to change rootwrap filters, I don't think that's going to fly.
16:28:40 <hemna> eharney, afaik it was
16:28:44 <smcginnis> hemna: +1 Yep
16:28:50 <geguileo> hemna: If we don't allow backports, and we'll be doing version bumps, we need a job to test os-brick against N-1 release on every patch, right?
16:29:00 <hemna> that's the only justification
16:29:05 <eharney> well, i'll say it this way, that's not the reason i'm interested in backports
16:29:17 <geguileo> By version bumps I mean bumping the upper constraints
16:29:58 <eharney> it's the same idea as cinder stable backports... you grab important fixes and assess risk vs benefit etc
16:29:59 <hemna> geguileo, yah to have newton get a new version it'd require a upper constraints bump
16:30:27 <geguileo> hemna: But then we should be making sure nothing in master gets merged that would break that, right?
16:30:33 <hemna> the one downside to just pulling the latest, is you'll get new features
16:30:33 <smcginnis> geguileo: The patch to raise u-c will test that, but that doesn't help make sure nothing gets in to break backwards compat before then.
16:30:43 <hemna> when you may have only wanted a simple critical bug fix
16:30:46 <geguileo> smcginnis: That's the problem
16:30:50 <smcginnis> geguileo: Yeah
16:31:00 <geguileo> smcginnis: By then, if it's broken we probably have no way of getting out
16:31:02 <winston-d> what's the highest os-brick version w/o privsep?
16:31:10 <geguileo> smcginnis: Because we can't do the bump or backports
16:31:14 <hemna> 1.4 ?
16:31:15 <geguileo> smcginnis: Same situation as we are now
16:31:15 <smcginnis> winston-d: 1.4. I believe.
16:31:45 <hemna> so from a distribution's perspective they'd just want bug fixes I'd guess
16:31:58 <hemna> and not be required to pull the latest version for an older release, just to get a fix in.
16:32:11 <smcginnis> geguileo: Well, if we backport and it fails when we try to raise to 1.4.1, we could always go for a 1.4.2, right. ;)
16:32:12 <winston-d> so I assume the stable os-brick would be do another 1.4.x release with some 1.5+ changes backported to 1.4.x?
16:32:28 <hemna> so for newton are we going to set the upper constraint to <= 1.7.0 ?
16:32:33 <smcginnis> winston-d: We might have to look at 1.2.1 since 1.2.0 was the cap for Mitaka.
16:32:36 <hemna> then any 1.6.X fixes can go in
16:33:06 <hemna> 1.6.0 is the latest release
16:33:12 <hemna> and is what newton will use
16:33:17 <winston-d> smcginnis: so bumping cap for stable branch is not allowed?
16:33:21 <smcginnis> It's currently 1.5 https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L201
16:33:21 <jungleboyj> hemna: I think that makes sense.
16:33:39 <smcginnis> hemna: We need to address the unit test failures from using 1.6 before we can raise it.
16:33:40 <geguileo> winston-d: It is allowed afaik
16:33:41 <hemna> eharney, does that make sense ?
16:33:52 <winston-d> nova and cinder is the only consumer/downstream project of os-brick, I assume.
16:34:04 <smcginnis> hemna: I was going to ask for a 1.6.1 that adds the connector mapping that Tony put up.
16:34:09 <hemna> winston-d, the cinderclient extension does
16:34:11 <hemna> as well
16:34:21 <hemna> smcginnis, +1
16:34:46 <eharney> it would be <1.7.0... but, i think so
16:34:57 <winston-d> ok, so if nova.mitaka & cinderclient extension.mitaka is happy iwht 1.4x os-brick, we can bump upper cap then.
16:35:20 <hemna> eharney, ah yah < not <=
16:35:21 <eharney> nova mitaka has u-c of ==1.2.0
16:35:44 <eharney> cinder mitaka has !=1.4.0
16:35:55 <jungleboyj> eharney: Oh yeah, we need to make sure not to forget Nova.  :-)
16:35:56 <hemna> winston-d, master u-c is 1.5.0
16:36:09 <hemna> so newton is already using privsep (as a requirement for nova)
16:36:14 <eharney> jungleboyj: the requirements process manages all of this centrally anyway, in theory... it should be pretty hard to forget and break it
16:36:33 <smcginnis> eharney: Oh yeah, I think 1.4 was actually where we added privsep, then everything blew up in grenade tests and there was the lengthy debate about how to handle upgrades.
16:36:34 <diablo_rojo> eharney, Lol, in theory.
16:36:42 <jungleboyj> eharney: :-)  *crossing fingers*
16:37:18 <winston-d> so 1.3.x then...
16:37:19 <smcginnis> Well, in the interest of time, we can look at doing stable releases if we need to. Let's move on.
16:37:23 <smcginnis> geguileo: That OK?
16:37:36 <hemna> smcginnis, I'm ok with it fwiw
16:37:44 <smcginnis> hemna: Thanks! :)
16:38:03 <smcginnis> Did we lose geguileo ?
16:38:15 <geguileo> smcginnis: No I'm here
16:38:18 <geguileo> lol
16:38:21 <smcginnis> geguileo: :)
16:38:29 <smcginnis> geguileo: You ok if I move on?
16:38:32 <jungleboyj> smcginnis: He started the fight and left.  ;-)
16:38:32 <hemna> I just really wanted to understand the reasoning and need.
16:38:47 <geguileo> smcginnis: If you set an agreed item I will be glad to move on  ;-)
16:38:57 <smcginnis> If we have a needm then there's a reason. :)
16:39:30 <DuncanT> 20 minute warning...
16:39:38 <smcginnis> geguileo: I think the agreed item is we will look at what can be backported safely, and if things needed can safely be backported we will do a stable release and raise the Mitaka upper constraints.
16:39:48 <smcginnis> Anyone absolutely against that?
16:40:00 <geguileo> smcginnis: I'm ok with that
16:40:14 <smcginnis> OK...
16:40:18 <smcginnis> #topic Add volume-type filter to Get-Pools
16:40:24 <tommylikehu_> yes, small feature https://review.openstack.org/#/c/362747/
16:40:25 <smcginnis> tommylikehu_: You're up.
16:40:39 <tommylikehu_> depends on https://blueprints.launchpad.net/cinder/+spec/allow-api-users-to-get-info-about-a-specified-pool
16:41:48 <smcginnis> Seems reasonable. So just like we have volume_backend=X extra specs, you're prosposing including pool as an explicit option?
16:41:53 * smcginnis hasn't read the spec yet
16:42:02 <eharney> is it true that you can always determine which types can and can't land on a pool in a meaningful way?
16:42:26 <bswartz> spec was published yesterday...
16:42:38 <tommylikehu_> smcginnis:yes
16:42:40 <smcginnis> #link https://review.openstack.org/#/c/362747/ Pool spec
16:42:46 <DuncanT> eharney: Almost totally true, and should be true
16:42:53 <tommylikehu_> lol
16:43:04 <smcginnis> tommylikehu_: We'll be reviewing specs for Ocata soon. Is there a specific point you wanted to discuss in the meeting?
16:43:16 <tommylikehu_> actual no
16:43:23 <smcginnis> tommylikehu_: Or just get visibility and awareness?
16:43:30 <smcginnis> tommylikehu_: OK, cool.
16:43:48 <smcginnis> tommylikehu_: I'll move along then. Thanks!
16:43:58 <smcginnis> #topic Whether use OVO object instead of ORM object in a function receiving OVO object through RPC
16:44:07 <smcginnis> Lisa's not here though.
16:44:07 <Guest36472> smcginnis: I am here
16:44:12 <smcginnis> Guest36472: Oh good.
16:44:37 <jungleboyj> Hiding as a guest.
16:44:43 <smcginnis> #link https://etherpad.openstack.org/p/patch268608
16:44:49 <Guest36472> let me clarify the problem: https://review.openstack.org/#/c/268609/31/cinder/volume/manager.py in the function of detach_volume, both ovo object and db object is used
16:45:11 <smcginnis> I'm looking to dulek and geguileo :)
16:45:37 <Guest36472> the problem is that in this patch I add corresponding interfaces in ovo object, and use ovo object instead of db object
16:45:38 <dulek> I'm here. ;)
16:45:58 <geguileo> smcginnis: I've reviewed both patches in question
16:46:18 <dulek> I thought we've agreed that this is fine for objects flying over RPC and the problem was if we want to switch from sending plain IDs to sending whole o.vo
16:46:19 <geguileo> smcginnis: And I don't think we really have any problem, but let's hear what Guest36472 has to say
16:46:34 <geguileo> dulek: +1
16:47:09 <Guest36472> smcginnis: geguileo: dulek: John raised a question whether should add usch ovo methods as seems it increases complex
16:47:28 <geguileo> Guest36472: I know, but we discussed it on the IRC channel
16:47:44 <geguileo> Guest36472: And I think he ended up saying that it was ok
16:47:56 <geguileo> At least that's what I last remember
16:48:23 <bswartz> when OVO was introduced, the theory was that we wouldn't need to use ORM objects anymore on RPC call handlers
16:48:27 <Guest36472> I didn't get his response from the irc. But anyway if both of you think it is ok, I will move on
16:48:42 <geguileo> Guest36472: I think it's OK
16:49:00 <geguileo> Just some nits I commented on the patches
16:49:13 <bswartz> it was supposed to act more or less like OVO does in nova, but without a conductor service
16:49:29 <Guest36472> geguileo: yes I just submitted the patches, but I think I still have some update to do
16:49:55 <geguileo> bswartz: Yeah, and I really think we should make our scheduler work as a conductor for OVOs
16:50:05 <Guest36472> geguileo: +1
16:50:16 <DuncanT> We should probably update the devref with details of where we're aiming to get to with this ovo work
16:50:24 <smcginnis> 10 minute warning
16:50:29 <DuncanT> geguileo: Why?
16:50:51 <dulek> DuncanT: That would help us with DB schema changes.
16:51:06 <geguileo> DuncanT: Because right now it's quite "fragile" and we have a lot of complex stuff going on to work around the lack of conductor
16:51:34 <dulek> DuncanT: Nova is handling a lot of DB upgtrade problems in o.vo because only conductor accesses the DB.
16:51:44 <dulek> (techically conductor and n-api)
16:51:54 <DuncanT> If we're going that way, add a conductor, don't overload the scheduler
16:52:12 <winston-d> DuncanT: +1
16:52:15 <geguileo> DuncanT: Well, this is quick work
16:52:17 * bswartz wonders if conductor is a better approach to rolling upgrades than what we have
16:52:19 <jungleboyj> DuncanT: Oh, we have been here before.  :-)
16:52:22 <dulek> DuncanT: Hm, +1, we might want to switch to something like Gannt one day
16:52:23 <DuncanT> c-api performance would suck if we got rid of direct db access in api
16:52:25 <geguileo> DuncanT: But I'm ok either way
16:52:31 <hemna> DuncanT, +1
16:52:53 <geguileo> DuncanT: Oh, but the idea wouldn't be to have an actual conductor
16:52:57 <DuncanT> geguileo: Can we talk in the cinder channel after the meeting? I'd like to understand the issues
16:53:04 <geguileo> DuncanT: It would only be a service to do the backporting of OVOs when necessary
16:53:09 <dulek> bswartz: It helps with schema changes - you can upgrade conductors in an atomic steps - requests will get queued in MQ.
16:53:14 <smcginnis> Might be good to take this there later since we still have another topic.
16:53:14 <geguileo> DuncanT: Ok
16:53:23 <geguileo> smcginnis: +1
16:53:34 <bswartz> dulek: I know how it works, what I don't know is whether it's superior to what we're trying to do
16:53:37 <dulek> Okay, so we've agreed Lisa's patches are okay?
16:53:37 <smcginnis> Guest36472: Thanks
16:53:48 <Guest36472> thanks all of yo
16:53:52 <Guest36472> s/yo/you
16:53:57 <smcginnis> dulek: I think that was what I was hearing.
16:54:09 <smcginnis> With some comments to address yet.
16:54:32 <smcginnis> #topic Marking NFS as unsupported
16:54:37 <smcginnis> DuncanT: Have at it. :)
16:54:49 * jungleboyj start crying
16:54:52 <jungleboyj> ;-)
16:54:53 <e0ne> :)
16:54:54 <DuncanT> So I bought this up. We defined a policy a few weeks ago, we should follow it
16:55:00 <diablo_rojo> jungleboyj, Lol
16:55:04 <smcginnis> jungleboyj: I was just typing up something along those lines! :)
16:55:05 <e0ne> DuncanT: +1
16:55:16 <hemna> DuncanT, because there is no NFS CI ?
16:55:16 <jungleboyj> DuncanT: +1
16:55:19 <jungleboyj> I agree.
16:55:22 <DuncanT> NFS fails to have CI and it fails to meet minimum features
16:55:31 <jgregor> DuncanT: +1
16:55:43 <DuncanT> (I did ping jungleboyj privately, for the record, to see how much pain this would cause)
16:55:52 <smcginnis> DuncanT: You also mention block driver in the meeting agenda as well...
16:55:58 <hemna> enable_unsupported_driver=True
16:56:05 <jungleboyj> So, mriedem Responded to the note I sent to the mailing list noting the first thing we should do is get the existing CI working without snapshots and cloning.
16:56:11 <DuncanT> Need to check if the raw block device driver meets minimum features or not
16:56:12 <eharney> i objected to doing this for Mitaka because it causes upgrade issues for people
16:56:17 <jungleboyj> DuncanT: I know, giving you a hard time buddy.
16:56:29 <smcginnis> eharney: Objected to what exactly?
16:56:29 <e0ne> DuncanT: it does, AFAIR
16:56:30 <eharney> jungleboyj: when i worked on CI, i didn't think it was valuable to make the job run w/o the snapshot features
16:56:32 <hemna> eharney, so does removing drivers.  that issue is dead.
16:56:33 <jungleboyj> I have baumann working on that now.
16:56:37 <DuncanT> eharney: It is meant to. It is an unsupported driver
16:56:49 <DuncanT> e0ne: Ok. The agenda item was purely to remind me to ask :-)
16:56:57 <eharney> hemna: DuncanT: i'll be satisfied with that when someone can explain what it gains us
16:57:12 <hemna> the driver code stays in tree.
16:57:19 <hemna> and the deployer can re-enable it.
16:57:29 <eharney> ok
16:57:31 <hemna> instead of having to go out to git and copy/paste code into their new tree.
16:57:31 <DuncanT> eharney: It encourages vendors to fix their shit, and the inconvenience encourages customers to pressure vendors into fixing their shit
16:57:32 <jungleboyj> eharney: It is just following our process.  We will get things fixed up and move on.
16:57:47 <eharney> DuncanT: the shit is being fixed at maximum shit-fixing speed now
16:57:53 <jungleboyj> eharney: It is a little silly but I think we should eat our own dog food here.
16:57:54 <hemna> at least they have a mechanism to getting access to their volumes.
16:58:01 <eharney> but it's fine if we'd like to go along with the policy, sure
16:58:02 <mriedem> eharney: you don't see value in a CI job that runs with the cinder NFS driver?
16:58:05 <mriedem> when hacking on said driver?
16:58:30 <eharney> mriedem: not what i said... i made the CI job.  i just intended to let it fail until snapshots landed
16:58:35 <DuncanT> eharney: This time, yes, but we have a process, we should follow it. If they fix it before release, we can remove the unsupported flag, and no hard done
16:58:41 <DuncanT> eharney: Same as any other vendor
16:58:44 <eharney> DuncanT: ok
16:58:47 <mriedem> eharney: being able to attach and detach a volume to a VM is kind of a big deal
16:58:50 <mriedem> regardless of snapshots
16:58:59 <jungleboyj> eharney: How long do you think before we can land the snapshot support?
16:59:02 <hemna> can we just skip the snapshot tests for now ?
16:59:11 <eharney> hemna: that's the proposal
16:59:13 <hemna> at least we have a ci up and running
16:59:14 <jungleboyj> hemna: ++
16:59:20 <hemna> ok, I'd be ok with that.
16:59:32 <hemna> we all skip tests for some reason or another at times.
16:59:41 <e0ne> hemna: +1
17:00:06 <smcginnis> In order to run the CI tests for this, the job will need to set the enable_unsupported_drivers option.
17:00:29 <smcginnis> If we add that flag.
17:00:35 <smcginnis> Shoot, time.
17:00:38 <smcginnis> Thanks everyone.
17:00:45 <DuncanT> I'll try to throw an unsupported driver patch up, it will be interesting to see what it looks like
17:00:45 <smcginnis> #endmeeting