15:00:22 <bswartz> #startmeeting manila
15:00:23 <openstack> Meeting started Thu Aug 11 15:00:22 2016 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:27 <openstack> The meeting name has been set to 'manila'
15:00:31 <bswartz> hello all
15:00:32 <cknight> Hi
15:00:36 <jseiler> hi
15:00:37 <tovchinnikova> \\//
15:00:37 <vponomaryov> hello
15:00:38 <ganso> hello
15:00:40 <xyang2> hi
15:00:44 <aovchinnikov> hi
15:00:51 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:00:55 <tbarron> hi
15:01:01 <bswartz> so there's no items proposed today ^
15:01:03 <markstur> hi
15:01:04 <zhongjun_> hi
15:01:04 <rraja> hi
15:01:20 <bswartz> we'll use today to discuss deadlines and n-3 priorities
15:01:35 <bswartz> #topic announcements
15:01:50 <bswartz> TODAY is the driver feature proposal freeze
15:01:52 <gouthamr> hello o/
15:02:15 <bswartz> starting tomorrow any new drivers or driver refactor patches should get an immediate -2
15:02:19 <mkoderer> hello
15:02:40 <gouthamr> bswartz: you mean "major" driver changes and new drivers?
15:03:01 <bswartz> gouthamr: no that's not how we phrased it
15:03:03 <ameade> o/
15:03:10 <ganso> bswartz: -1
15:03:13 <bswartz> the feature proposal freeze for everything else is in 1 week
15:03:25 <dustins_> \o
15:03:29 <ganso> bswartz: so what can be proposed between today and next week?
15:03:39 <bswartz> ganso: any small feature
15:03:45 <ganso> bswartz: I assumed very small driver changes could be proposed up to next week
15:03:54 <bswartz> implementation of a new feature by a driver, for example
15:03:57 <bswartz> a new config option
15:04:02 <ganso> bswartz: oh, ok
15:04:04 <bswartz> ganso: yes
15:04:19 <zhongjun_> bswartz: How about share backup deadline? next week?
15:04:23 <bswartz> today's deadline is just whole new drivers
15:04:42 <ganso> zhongjun_: share backup within major features proposal freeze
15:04:45 <gouthamr> bswartz: ah, that clarifies.. thank you.
15:04:50 <bswartz> and we lump driver refactors in too because they tend to be as painful to review as whole new drivers
15:04:54 <xyang2> bswartz: and big driver refactors
15:06:06 <bswartz> zhongjun_: the deadline for major new features was 3 weeks past, and the backup feature proposal met that deadline
15:06:20 <bswartz> however we have a lot of new features in review right now
15:06:40 <bswartz> just because stuff is meeting deadlines doesn't mean we'll merge it for newton -- you need to get reviews and +2s
15:06:56 <bswartz> if reviews aren't happening, then chances are slim at this point
15:07:14 * bswartz realizes he should have changed the topic a while ago
15:07:16 <bswartz> #topic deadlines
15:07:38 <zhongjun_> bswartz: oh, I see
15:07:42 <bswartz> as everyone knows, the deadline that really matters is the feature freeze itself
15:07:57 <bswartz> #link http://releases.openstack.org/newton/schedule.html
15:08:15 <ganso> bswartz: well we got a priority list, and reviewers assigned, if reviewers assigned are not reviewing, what else can we do?
15:08:22 <bswartz> R-5 is feature freeze and we aim to cut the n-3 milestone early in that week
15:08:43 <mkoderer> bswartz: this mean all non-merged features get -2?
15:08:46 <bswartz> ganso: that's what I'm getting to next
15:09:07 <mkoderer> after R-5
15:09:34 <bswartz> mkoderer: any feature proposed after Aug 18 23:59:59 UTC should get immediate -2
15:10:12 <bswartz> stuff with -2 can apply for a FFE but those are rarely granted
15:10:27 <mkoderer> bswartz: ok "proposed" stuff only
15:10:39 <bswartz> stuff that doesn't make it by the feature freeze (the n-3 tag) just gets retargeted to ocata
15:11:10 <mkoderer> ok
15:11:17 <bswartz> I suspect a few things will not make it, but which things those are remains to be seen
15:11:27 <bswartz> this brings me to the etherpad...
15:11:30 <bswartz> #topic review focus
15:11:44 <bswartz> #link https://etherpad.openstack.org/p/manila-newton3-priorities
15:12:37 <bswartz> if your name is on this etherpad you should have at least taken a look at everything you signed up for by now
15:12:44 <bswartz> hopefully offered some feedback too
15:13:21 <bswartz> I'm going to look for patches which reviewers signed up who haven't reviewed and send them nastygrams
15:13:55 <bswartz> by the end of this week please at least have your -1s posted
15:14:06 <bswartz> so the authors have time to respond
15:14:51 <bswartz> if we don't get some stuff ready to merge in the next week or so, the merge conflicts at the end of the release will be a nightmare and stuff will fall out of the release just due to slowness in the gate or other silly reasons like that
15:15:34 * mkoderer needs the docker driver merged :)
15:15:48 <bswartz> I'll point out that this release we have more features proposed than we've ever had before
15:16:13 <bswartz> I think it shows how the community has grown and become more active, which is great
15:17:22 <bswartz> however it means the core team will be stressed more than ever before, and vponomaryov will unfortunately not be available for the next 2 weeks due to a much-deserved vacation
15:17:32 <xyang2> bswartz: vponomaryov is on vacation and won't be back until after newton-3.  do we have someone who can vote on his behave?:)
15:17:49 <bswartz> thankfully we now have tbarron who can do all of vponomaryov's work :-)
15:18:05 <xyang2> tbarron:  great:)
15:18:14 <tbarron> vponomaryov is getting lazy i see
15:18:34 <bswartz> lol
15:18:50 <vponomaryov> tbarron: show how core member should look like!
15:18:57 <mkoderer> tbarron: we expect 7/24 reviews
15:19:03 <vponomaryov> tbarron: I will return back and check it out
15:19:17 * tbarron should be getting worried
15:19:23 <bswartz> I just want to make sure to set people's expectations right -- meeting deadlines is no guarantee of merging
15:19:48 <vponomaryov> tbarron: don't worry, I believe in you
15:20:02 <bswartz> personally, my top priority is having the share migration stuff merge because I want to remove the experimental tag on that and I believe we're in range of doing that
15:20:17 <ganso> bswartz: up to next week, right?
15:20:19 <markstur> mkoderer, 7/24 = 0.29167 how about 7x24 reviews instead?
15:20:26 <vponomaryov> bswartz: remove tag in newton?
15:20:44 <bswartz> vponomaryov: that's my hope
15:20:44 <mkoderer> markstur: :)
15:20:53 <vponomaryov> oh no
15:20:59 <xyang2> vponomaryov: newton-3 is Aug 29-02, so you may still make it
15:21:17 <markstur> while vponomaryov  is on vacation we can untag things and he can't object
15:21:32 <bswartz> if we remove the experimental tag, it would probably happen between N-3 and RC1
15:21:37 <ganso> I can have the patch that removes experimental up for next week deadline, and merged before Augh 29th
15:21:43 <tbarron> markstur: in python 2.7 7/24 == 0
15:21:55 <ganso> bswartz: really? we can do it in bugfix week?
15:21:56 <bswartz> and it would depend on us being perfectly happy with the API as-is
15:22:16 <bswartz> ganso: I view it as a QA thing rather than a new feature
15:22:24 <ganso> bswartz: ok
15:22:30 <bswartz> that's definitely up for debate
15:23:01 <markstur> tbarron, good catch
15:23:03 <bswartz> but removal of an experimental tag shouldn't cause any noticeable change other than you don't need to send that header anymore
15:23:32 <bswartz> py3 > py2
15:23:41 <vponomaryov> bswartz: we should not require it starting with some microversion
15:24:05 <vponomaryov> bswartz: or it should be supported only in latest
15:24:08 <ganso> bswartz: oh, it will include a microversion bump as well, won't it?
15:24:12 <bswartz> vponomaryov: right -- the removal of the experimental tag should be microversioned
15:24:22 <bswartz> okay so that would be another noticeable change
15:24:24 <bswartz> hmm
15:24:34 <bswartz> maybe the late timing is less good because of that
15:24:55 <bswartz> in that case I'd propose removing it as close to FF as possible, ideally before
15:25:41 <bswartz> alright so I'll open up the floor for any specific topics about features/reviews you want to discuss
15:25:45 <bswartz> #topic open discussion
15:26:00 <ganso> https://review.openstack.org/#/c/350647/
15:26:14 <ganso> we should decide something related to that ^
15:26:16 <vponomaryov> ganso: ))
15:26:37 <bswartz> ganso: I didn't -2 it
15:26:42 <vponomaryov> yes ))
15:26:45 <vponomaryov> yes* )
15:26:47 <vponomaryov> yet*
15:26:55 <tbarron> can we come back to that in a moment, it will take a bit
15:26:55 <bswartz> I just registered my objection to that approach
15:27:01 <tbarron> gate is  broken but we have https://review.openstack.org/#/c/354023
15:27:22 <bswartz> I think a possible solution there is to merge that fix as is, and backport to mitaka, then also merge a better fix if someone can write that better fix
15:27:30 * bswartz looks at gouthamr
15:27:32 <tbarron> i'm inclined to raise a BZ for the residual work and have us go on and merge it.
15:28:35 <ganso> tbarron: sorry, what is a BZ?
15:28:38 * tbarron will wait and bring that topic up in #openstack-manila on the hour
15:28:48 <zhongjun_> <ganso>
15:28:50 <bswartz> BZ = bugzilla, which isn't really relevant for us
15:28:55 <tbarron> ganso: sorry, i meant to say LP
15:28:56 <ganso> oh
15:29:02 <tbarron> bug
15:29:12 <ganso> so it is relevant to us hehe
15:29:27 <tbarron> keep talking on the original subject, i was rude
15:29:58 <bswartz> I said what I wanted to -- gouthamr is AFK an unable to respond
15:30:18 <vponomaryov> maybe he is working hard on that fix? ))
15:30:21 <ganso> bswartz: so if you agree with merging as is and fixing later, why keep -1?
15:30:37 <bswartz> ganso: because I'm not going to be the one to merge it
15:31:00 <vponomaryov> bswartz: removal of -1 does not mean +2
15:31:24 <bswartz> my preference is for the correct fix to land in newton sooner rather than later
15:31:46 <bswartz> however since it's tied up with migration I may have to compromise because I cant' have everything I want
15:32:28 <ganso> bswartz: so it would be good to state that you agree that it can be merged, instead of opposing it (as you just stated), so other cores may not look at -1 and assume you have strong feelings against
15:32:48 <bswartz> ganso: okay
15:33:09 <bswartz> so what's with these failed unit tests
15:33:12 <vponomaryov> ganso: achiement unlocked - persuaded PTL
15:33:22 <tbarron> zengyingzhe: is probably in a TZ where people are sleeping now but has a fix for broken gate here: https://review.openstack.org/#/c/354023
15:33:22 <vponomaryov> s/achiement/achievement/
15:33:23 <ganso> vponomaryov: lol
15:33:26 <bswartz> are they new? what caused them to start failing suddenly?
15:33:50 <tbarron> bswartz: that's one of my questions behind my -1
15:34:16 <tbarron> the other issue is that we need a followup bug for the tech debt incurred
15:34:36 <ganso> it seems to me something messed up the encoding in huawei drivers... again
15:34:41 <tbarron> but probably we want to go on and unbreak gate, which this patch does
15:34:54 <bswartz> tbarron: indeed
15:35:07 <bswartz> zhongjun_: you know anything about this?
15:35:19 <tbarron> ganso: but git blame wasn't showing me a recent relevant change (maybe I'm just not seeing it)
15:35:40 * bswartz assumes zhongjun_ and zengyingzhe work together
15:35:41 <zhongjun_> bswartz: a little
15:35:45 <ganso> tbarron: it seems there hasn't
15:36:11 <bswartz> tbarron: is the breakage reproducible on your laptop?
15:36:17 <tbarron> bswartz: yes
15:36:22 <tbarron> running py35
15:36:24 <bswartz> I haven't run unit tests revently
15:36:28 <bswartz> recently*
15:36:57 <bswartz> but py35 is nonvoting -- does it happen with py34?
15:37:22 <tbarron> upstream yes, i just reprod with py35 since that's what I have locally
15:37:27 <bswartz> I see
15:37:39 <mkoderer> just a quick note for drivers maintainers of DHSS=true drivers: it's might needed to incorporate the MTU fix (https://review.openstack.org/#/c/349506/) in your driver
15:37:43 <tbarron> i'm confident that it would show with py34
15:38:03 <mkoderer> enterprise users love MTU = 9000 and not 1500 ;)
15:38:09 * gouthamr is back
15:38:10 <tbarron> it's basic py3 encoding stuff, but I don't see the trigger for it showiing up recently
15:38:17 <bswartz> zhongjun_: do you know when we might see a followup patch from zengyingzhe which adds back the test coverage without causing the problem we're currently seeing?
15:38:38 <zhongjun_> bswartz: I know he fix the buy in his environment.
15:38:48 <bswartz> mkoderer: +1
15:38:50 <tbarron> mkoderer: did you address gouthamr's comments, when you do I think cknight and I will push it through
15:39:01 <mkoderer> tbarron: yes I did
15:39:08 <cknight> tbarron: hopefully today
15:39:10 <gouthamr> mkoderer: i think we need a tempest test
15:39:15 <tbarron> mkoderer: ok, will look
15:39:29 <gouthamr> mkoderer: it's a really simple one and i commented on the patch as to where/how to add one..
15:39:50 <bswartz> gouthamr: would that test be driver-dependent?
15:40:04 <gouthamr> mkoderer: i'm okay with that going in after the patch though..  we've kind of tested it pretty vigorously downstream..
15:40:16 <mkoderer> gouthamr: you mean a tempest test to check other mtu values?
15:40:24 <tbarron> zhongjun_: he just removed some offending lines but we don't know what triggered the issue since (i think) those lines were old
15:40:38 <vponomaryov> don't forget to update standalone network plugin too, it is tested in dummy driver
15:40:40 <gouthamr> bswartz: nope.. copying the mtu from network provider to share network
15:40:41 <tbarron> zhongjun_: and he said he'd need a followup patch
15:40:42 <mkoderer> all gate jobs would simply ignore since they don't use network plugins
15:40:42 <zhongjun_> bswartz: maybe I could call he, if he is didn't sleep
15:40:50 <vponomaryov> mkoderer^
15:40:59 <tbarron> zhongjun_: i think to get the test coverage back
15:41:06 <mkoderer> vponomaryov: I already had a -1 becasue of the missing standalone driver
15:41:09 <mkoderer> it's now in
15:41:16 <bswartz> zhongjun_: we don't need to wake him up -- we just want to make sure the followup mentioned in the commit message actually happens
15:41:24 <gouthamr> mkoderer: not different mtu values, get the one that's set in the provider so you can verify that in the share network that gets created
15:41:29 <vponomaryov> mkoderer: and new mtu is set for dummy driver?
15:41:55 <gouthamr> vponomaryov: +1 -> we can test that stuff.
15:41:55 <tbarron> zhongjun_: if we have a launchpad bug for the followup and it will include root cause analysis, then I think we could probably merge the fix now since it does make unit tests pass (by removing stuff)
15:42:10 <mkoderer> vponomaryov: yeah lets test it with the dummy driver
15:42:15 <gouthamr> tbarron: +1 i ran the tests locally too, can verify
15:42:32 <bswartz> okay any other topics?
15:42:40 <cknight> bswartz: yes
15:42:49 <cknight> Do we have any ZFS experts besides bswartz and vponomaryov?  Valeriy was on the hook to do the 1st-party driver work for the revert-to-snapshot feature.  His late-breaking vacation plans mean that feature is at risk for Newton.
15:43:04 <cknight> Please let me know ASAP if you want to do some driver work to enable gate testing that feature.  Otherwise, I'll abandon it.
15:43:27 <vponomaryov> cknight: why abandon?
15:43:38 <ganso> cknight: abandon revert-snapshot?
15:43:45 <tbarron> abandon or just let it roll over to O
15:43:49 <bswartz> you don't need to be a zfs expert to implement the revert-to-snapshot thing
15:43:51 <markstur> Don't know how to spell ZFS
15:44:02 <tbarron> zee or zed?
15:44:09 <bswartz> argh
15:44:12 <cknight> vponomaryov, ganso: It's been sitting there waiting for a long time.  If it has to wait further, I'll let someone else run with it.
15:44:33 <gouthamr> bswartz: yeah, looks straightforward, if you look at vponomaryov's replication impl :D
15:44:33 <bswartz> vponomaryov calls it "Zed FS" because he learned british english
15:44:45 <gouthamr> :D
15:45:21 <bswartz> cknight: tempest tests also need writing, correct?
15:45:24 <vponomaryov> bswartz: I guess it is remote audio decoding problem ))
15:45:41 <cknight> bswartz: yes.  it's one API, so testing is trivial.  I could still do that.
15:46:13 <bswartz> cknight: maybe we can figure something out
15:46:21 <gouthamr> cknight: i think negative tests for all the API validation can be added without the first party driver impl
15:46:48 <cknight> gouthamr: sure, but we're pretty good about requiring gate testing of new features
15:47:16 <bswartz> for the record I like British english -- I just can never get used to the Z = "zed" thing
15:47:35 <vponomaryov> bswartz: how would you call it?
15:47:41 <bswartz> zee
15:48:17 <bswartz> americans and canadians say Z = "zee"
15:48:31 <bswartz> okay I think we're out of productive topics
15:48:33 <bswartz> anything else?
15:48:35 <gouthamr> yes
15:48:41 <gouthamr> https://review.openstack.org/#/c/317152/ needs reviews
15:48:51 <ganso> I did not know about zee / zed, for me it was productive
15:48:54 <gouthamr> it's the install guide for manila, that's moving in tree
15:49:11 <bswartz> gouthamr thanks for doing that work
15:49:28 <gouthamr> tbarron, toabctl: it involves RDO, OBS specific instructions.. could you guys take a look
15:49:36 <bswartz> gouthamr have you poked dencaval to get his review?
15:49:58 <gouthamr> bswartz: i did.. he hasn't responded yet
15:49:59 <cknight> gouthamr: thanks for handling that
15:50:15 <toabctl> gouthamr, for the OBS side - ajaeger already reviewed it. should be fine
15:50:19 <bswartz> alright thanks everyone
15:50:20 <cknight> *thinks gouthamr would be a great docs liaison*
15:50:22 <gouthamr> toabctl: nice.. yep
15:50:29 * gouthamr oh no you don't
15:50:33 <bswartz> core reviewer's get your -2s ready for the deadlines tonight and next week
15:50:36 <toabctl> cknight, +1 :)
15:50:52 <bswartz> #endmeeting