15:00:19 <bswartz> #startmeeting manila
15:00:19 <openstack> Meeting started Thu Sep  3 15:00:19 2015 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:24 <openstack> The meeting name has been set to 'manila'
15:00:30 <ameade> o/
15:00:30 <tbarron> hi
15:00:30 <cknight> Hi
15:00:38 <markstur> hi
15:00:39 <toabctl> hi
15:00:40 <akerr> o/
15:00:40 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:00:43 <lpabon_> o/
15:00:53 <dustins> \o
15:00:54 <vponomaryov> hello
15:00:55 <u_glide> hi
15:00:55 <rraja> hi
15:01:07 <bswartz> also csaba has a topic he couldn't add due to an OpenID failure
15:01:20 <ganso_> hi
15:01:36 <bswartz> #topic liberty-3 / feature freeze
15:01:36 <cFouts> hi
15:01:45 <csaba> hi
15:01:59 <ayma_> hi
15:02:05 <bswartz> so liberty-3 was tagged about an hour ago
15:02:14 <bswartz> #link http://git.openstack.org/cgit/openstack/manila/tag/?id=1.0.0.0b3
15:02:22 <bswartz> that's the good news
15:02:39 <bswartz> the bad news is that 7 blueprints and countless bugs were not merged due to a serious gate problem
15:03:13 <akerr> do we know the cause of the gate issue?
15:03:21 <bswartz> we're going to grant technical FFE exceptions for stuff that was ready to merge when the gate broke
15:03:57 <vponomaryov> akerr: yes, https://bugs.launchpad.net/nova/+bug/1491325
15:03:58 <openstack> Launchpad bug 1491325 in OpenStack Compute (nova) "nova api v2.1 does not allow to use autodetection of volume device path" [Critical,In progress] - Assigned to Davanum Srinivas (DIMS) (dims-v)
15:04:13 <bswartz> although a technical FFE is no gurauntee that stuff will get in to liberty
15:05:12 <bswartz> nova created a bug on Tuesday night which caused problems for us on Wednesday morning
15:05:53 <vponomaryov> bswartz: actually bug was for a long time, Nova switched us to place where it was located
15:05:54 <dustins> just us or everyone who touches nova?
15:06:14 <bswartz> they create a server fix, then blocked the fix, then created a client fix, but did not tag the client fix so it wouldn't help us, and now they have unblocked the original server fix and it's on it s way through the gate again
15:06:31 <vponomaryov> dustins: Nova has bug in their API compatibility v2.1 -> v2.0
15:06:46 <dustins> vponomaryov: Ah, I gotcha, thanks!
15:07:25 <vponomaryov> dustins: so this bug is not only for liberty, but also existing stable branches
15:07:36 <bswartz> the upshot is that if you add Depends-On: Ibfd83b6abdfeec328019246a372363cada53869e to your patch it should pass gate
15:08:07 <csaba> bswartz: I thought what I'm to to is to rebase my patches over said one
15:08:12 <bswartz> or you can rebase on top of https://review.openstack.org/#/c/219788/ after valeriy updates that one to depend on Ibfd83b6abdfeec328019246a372363cada53869e
15:08:48 <vponomaryov> csaba: dep on https://review.openstack.org/#/c/219788/ can make gates more stable
15:09:11 <vponomaryov> csaba: because of workaround of another bug, now in Neutron
15:09:24 <bswartz> one way or another we will get past the gate problem
15:09:49 <bswartz> however we need to be aware that we are now eating into bugfixing time
15:10:18 <csaba> vponomaryov: so you mean I should resubmit with "Depends-On: I26dd32b1de8cceeaa6dc674092efec683df71889" indeed
15:10:35 <csaba> (id of https://review.openstack.org/#/c/219788/)
15:10:56 <bswartz> the FFE for technical reasons will only extend for around a day after the gate becomes unblocked (hopefully by tonight)
15:11:00 <vponomaryov> csaba: you can, but not forced
15:11:22 <bswartz> if stuff can't get workflowed by then we will have to push stuff out to mitaka
15:11:35 <markstur> vponomaryov, You didn't update the depends on there yet
15:11:59 <bswartz> so anyone that has stuff waiting to go in, make sure you're online and actively working on making your stuff pass check jobs and get your +2s
15:12:07 <vponomaryov> markstur: 3 sec ago
15:12:10 <vponomaryov> markstur: =)
15:12:27 <bswartz> vponomaryov: +1
15:12:35 <markstur> vponomaryov, took 4 secs to get to california
15:12:43 <bswartz> lol
15:12:48 <csaba> bswartz: do we discuss the possibility of non-technical FFEs here?
15:13:13 <bswartz> csaba: for those we follow the regular process
15:13:15 <iben> is anyone abel to recommend python 2 versus 3 for converting a bunch of bash scripts ?
15:13:24 <bswartz> after you get a -2 you request exception on the ML
15:13:29 <vponomaryov> too windy, dove flies too slow =)
15:13:43 <iben> sorry for jumping into the meeting -
15:13:56 <csaba> bswartz: why does something get a -2 that won't be merged to liberty?
15:14:01 <bswartz> I'll be watching the get closely today and I'll announce the all clear and set the deadline for stuff to merge
15:14:38 <cknight> bswartz: Are you going to briefly review the 7 targeted BPs?
15:14:50 <bswartz> -2 is just to signal that something isn't ready for merge
15:15:01 <csaba> OK
15:15:23 <bswartz> cknight: yes I want to assuming we have time
15:16:15 <bswartz> but the way I expect things to go in the next hour or 2 every patch should be resubmitted and start passing check jobs
15:16:49 <bswartz> when I see that I'll announce a deadline of Friday night or Saturday to get stuff merged again
15:16:59 <bswartz> and when the deadline arrives we'll -2 stuff as usual
15:17:50 <csaba> bswartz: basically what's the difference between "Depends-On: Foo" and being rebased over Foo?
15:17:58 <bswartz> core reviewers: the moment you see +1 from jenkins start merging stuff that's ready to merge though
15:18:11 <bswartz> csaba: depends-on work across projects
15:18:30 <bswartz> csaba: honestly I'm surprised it works within a project
15:18:44 <csaba> ah OK got it so the suggested depends-on because the referred fix is in nova
15:18:51 <csaba> bulb's up!
15:18:59 <vponomaryov> bswartz: why surprised?
15:19:05 <bswartz> https://review.openstack.org/#/c/219788/ should be the first thing that's merged though
15:19:10 <markstur> rbase also gives you a chance to deal with  merge conflicts. I'd assume depends on would fail that
15:19:37 <vponomaryov> markstur: yes, it will, but while it is not, it is ok
15:19:44 <bswartz> vponomaryov: just because it's an inferior way to do things, for the reason markstur said
15:20:43 <bswartz> okay so let's quickly go through the remaining BPs and bugs and see if any need discussing
15:21:03 <bswartz> #link https://launchpad.net/manila/+milestone/liberty-rc1
15:21:17 <bswartz> #topic share migration
15:21:55 <cknight> So my concern with share migration is the lack of functional tests.  I haven't yet succeeded in getting migration to work.
15:22:00 <bswartz> this has a -1 about functional tests
15:22:12 <bswartz> ganso_: can you add functional tests for it?
15:22:24 <ganso_> bswartz: I can start working on it right now
15:22:29 <cknight> This is a major feature, albeit experimental, so it should have some level of Tempest coverage.
15:22:47 <bswartz> yes my stance is that all features need funcitonal tests coverage
15:23:21 <bswartz> ganso_: I also think the concern that others can't get it to work is a problem
15:23:26 <markstur> There's always a trade-off of something "experimental" going late in release vs early in the next
15:23:31 <bswartz> who else has downloaded and tested migrations?
15:23:45 <markstur> crickets
15:24:00 <ganso_> bswartz: I need to see logs and check what errors are poping up
15:24:06 <bswartz> markstur: the whole point of "experimental" is to make those kinds of distinctions matter less though
15:24:29 <bswartz> we're on a 6 month release cycle, which is fairly fast
15:24:47 <markstur> Agreed.  I like it as experimental.  I would suggest waiting otherwise.
15:24:48 <bswartz> if something misses one release and slips to the next it should not be a big deal
15:25:04 <bswartz> however experimental lets us merge stuff when its ready and get feedback earlier
15:25:21 <ganso_> bswartz: I think that since we are marking it experimental, most bugs, edge cases, incompatiblity with some driver vendors, will be detected in liberty
15:25:34 <bswartz> so there are 2 concerns that need addressing with migrations
15:25:38 <akerr> bswartz: but experimental should still work in the majority of common cases
15:26:01 <ganso_> bswartz: if we slip to mitaka, it might still not have a very good coverage because not many people would have tested it
15:26:02 <bswartz> akerr: experimental APIs should work in at least 1 common case
15:26:05 <cknight> akerr: +1  Ready == working in some capacity.  It could be something I'm doing, but I need to see it working in host-copy mode with my driver.
15:26:58 <akerr> 1 common case seems like a really low bar
15:27:24 <ganso_> we cannot guarantee it will work with all drivers at this moment, that is why it is experimental
15:27:38 <bswartz> I would still like to see migration in liberty, but as we know it needs enhancements in mitaka anyways to work in all cases it would not be terrible to delay the feature
15:27:40 <ameade> akerr: +1, experimental shouldn't mean half done (lets avoid a philosophical debate)
15:27:46 <ganso_> but if it is proved to work with generic driver (and I understand functional test would help prove that) then it is something
15:28:07 <cknight> ganso_: +1  Working tests will go a long way.
15:28:09 <bswartz> ameade: yes that's important
15:28:11 <ameade> ganso_: I am cool with it only working with generic
15:28:17 <tbarron> ganso_: +1
15:28:37 <bswartz> however ganso_ has had code in gerrit for MONTHS and nobody started seriously testing it until last few weeks
15:28:58 <akerr> agree, i just don't think experimental should be used to merge what are essentially WIP patches.  If it works in generic that's fine
15:29:05 <ganso_> bswartz: +1
15:29:41 <bswartz> liberty has been complicated with the dependencies caused by share instances
15:29:45 <vponomaryov> akerr: functional tests say us that it works
15:29:55 <ganso_> I also had a patch to work without share instances, we discussed that in a meeting, the one which had a driver_id field
15:29:57 <vponomaryov> akerr: there is no such for the moment
15:30:00 <bswartz> let's give ganso_ a chance to add functional tests and show that it works
15:30:28 <bswartz> we have to move on due to time
15:30:39 <markstur> +1
15:30:44 <bswartz> #topic consistency groups
15:30:58 <markstur> +1 for working working migration (and moving on)
15:31:02 <bswartz> this one has 4 patchsets
15:31:38 <akerr> 5 if you include generic driver and tempest tests
15:31:39 <ameade> there are 5 changesets if you count generic driver
15:31:46 <bswartz> support for CGs was added to the generic driver recently at my request
15:31:46 <vponomaryov> markstur: do not say twice twice =)
15:31:52 <bswartz> #link https://blueprints.launchpad.net/manila/+spec/manila-consistency-groups
15:31:55 <bswartz> akerr: ^
15:32:40 <akerr> bswartz: https://review.openstack.org/#/c/215346/
15:32:41 <ameade> most of these patches have been reviewed by vponomaryov, u_glide, and xyang1
15:33:00 <ameade> first patch in the chain
15:33:02 <ameade> #link https://review.openstack.org/#/c/215343/
15:33:07 <bswartz> looks like the base of the dependency chain now has a depends-on for valeriy's gatefix so we should see these pass check jobs in an hour or so
15:33:09 <cknight> ameade: I've also reviewed them extensively internally for weeks.  The quality is high, IMO.
15:33:40 <ameade> there are patches for both netapp cdot and generic driver support
15:33:47 <ameade> it's been heavily tested with both
15:33:49 <cknight> u_glide: We need you to look at the rebase on share instances.
15:33:52 <bswartz> xyang1: you were the one who raised concerns about the API design with this one, are you satisfied?
15:34:01 <vponomaryov> bswartz: Nova's one of jobs failed
15:34:09 <u_glide> cknight: I will take a look
15:34:25 <xyang1> bswartz: I have not got chance to take another look
15:34:37 <ameade> u_glide: ty, i added all the unittest coverage i had missed and i believe i addressed all the other comments
15:34:59 <bswartz> xyang1: if you have issues express them soon
15:35:10 <xyang1> bswartz: Ok
15:35:12 <bswartz> otherwise I feel okay about merging CGs
15:35:28 <ameade> they will need to be rebased on top of version 2 when that merges
15:35:53 <bswartz> it was just before the deadline, but the quality was good, and furthermore the way the feature is implemented puts little risk on existing codepaths
15:36:35 <bswartz> most importantly, it's marked experimental so we can fix anything that needs fixing or we can even choose to revert it in mitaka if it turns out to be terrible
15:36:39 <akerr> v2 patch should be leaving our internal gate in about 8 minutes
15:36:43 <xyang1> bswartz: It will be better for such a big change to be submitted earlier though
15:37:00 <bswartz> xyang1: absolutely agree
15:37:22 <bswartz> I set the deadline so that we'd all have 2 weeks to review stuff
15:37:38 <markstur> for manila-client, we have CG and migration in "L3"
15:37:48 <bswartz> if 2 weeks isn't enough for big things we need to talk about moving the FPF date for Mitaka to 3 weeks maybe
15:38:03 <markstur> I assume those go with the features
15:38:08 <xyang1> But such a big change should have more than 2 weeks review time
15:38:16 <bswartz> markstur: the client LP is a bit of a mess
15:38:19 <ameade> markstur: +1
15:38:29 <lpabon_> bswartz: i thought we discussed at Vancouver that CGs for file systems didn't really apply as they do for block, or did I miss something
15:39:11 <bswartz> markstur: we'll clean that up later
15:39:36 <bswartz> xyang1: what do you propose? an earlier deadline for "big" features and a later deadline for "small" features?
15:39:51 <xyang1> bswartz: I think that is better
15:39:57 <bswartz> it's not a bad idea, except that it will be hard to draw the line between big and small
15:39:57 <lpabon_> I guess my question is, what is the use case for CGs for file systems?  Was one found?
15:40:00 <cknight> lpabon_: There are definitely use cases for CGs with file systems, most notably databases with data and logs on different paths.
15:40:41 <bswartz> everyone will claim that their feature is really small
15:40:53 <lpabon_> cknight: ah i see, so that logs could be on a different volume type, since they are write only
15:41:00 <tbarron> well, no one will claim that for CGs :-)
15:41:04 <bswartz> lpabon_: the database that uses multiple shares use case was a compelling one for me
15:41:33 <cknight> bswartz: +1 for moving FPF earlier.
15:41:58 <markstur> At mid-cycle it seemed we'd wait on CG until we had better defined customer need. It seeme "experimental" has helped move things up (plus working code!)
15:42:00 <lpabon_> yeah, i could see that, but most of dbs that do that use raw access to block storage afaik... but I could see a use case for file based logs
15:42:02 <bswartz> the topic of the Mitaka FPF will be discussed and decided later
15:42:24 <bswartz> in the interest of time we have to move on though
15:42:38 <bswartz> again, please use gerrit to provide feedback
15:42:59 <bswartz> #topic Mount Automation Framework
15:43:07 <bswartz> #link https://blueprints.launchpad.net/manila/+spec/mount-automation-framework
15:43:07 <xyang1> bswartz: We can measure by number of lines, not include tests?
15:43:12 <bswartz> #link https://review.openstack.org/#/c/201669/
15:43:19 <cknight> I've read through this one, it seems fine.
15:43:29 <bswartz> vponomaryov: ^ needs rebase
15:43:43 <vponomaryov> bswartz: why?
15:43:46 <bswartz> xyang1: let's discuss it in tokyo
15:43:50 <xyang1> Ok
15:43:53 <vponomaryov> bswartz: it is ok, its dependency is merged
15:43:54 <bswartz> vponomaryov: gate fix
15:43:59 <cknight> But I'd again ask about Tempest coverage.  vponomaryov, is it needed?
15:44:17 <vponomaryov> cknight: it is desired
15:44:28 <vponomaryov> cknight: but we do not have strict requirement
15:44:29 <bswartz> cknight: this feature is an internal one -- no API impact
15:44:38 <cknight> bswartz: Good point.
15:44:55 <cknight> bswartz: We still want a contrib example of how a client could use this for automounts, right?
15:44:56 <bswartz> the plan was to provide samples for how it can be used, but ultimately it's up to admins to implement the hooks
15:45:11 <bswartz> cknight: yes I'm expecting contrib/docs samples for how to use this feature
15:45:12 <vponomaryov> cknight: we have POC in gerrit
15:45:17 <bswartz> but the feature itself looks mergeable to me
15:45:23 <cknight> bswartz: +1
15:45:36 <vponomaryov> note: it is in "base" condition
15:45:43 <vponomaryov> and definitely will require updates
15:45:58 <cknight> vponomaryov: Can you clarify?  What else is needed?
15:46:29 <bswartz> vponomaryov: rebase on top of https://review.openstack.org/#/c/219788/ would make it easier to pass through gate
15:46:35 <vponomaryov> cknight: like ganso proposed , could be added info about share servers in notification
15:46:46 <vponomaryov> cknight: that is not there atm
15:46:59 <lpabon_> cknight: is there a way for a driver to use the automount code to insert something into the VM.. like say.. a glusterfs ssl certificate :-)
15:47:15 <bswartz> lpabon_: it's not a feature for drivers, it's a tool for the admin
15:47:27 <lpabon_> :(
15:47:34 <bswartz> the admin could choose to use it in the way you suggest
15:47:40 <lpabon_> :)
15:47:43 <lpabon_> cool
15:47:49 <bswartz> but we'd need to provide docs/samples for that use case and it would be up to the admin to do it
15:48:06 <lpabon_> true
15:48:36 <bswartz> the tricky thing about mount automation is that because it means so many different things to different people, all solutions will have to have some administrator involvement
15:48:39 <vponomaryov> <offtopic> there is local fix for Nova bug: https://review.openstack.org/#/c/220204/ in Manila</offtopic>
15:49:03 <bswartz> there will never be a one-size-fits-all mount automation solution I'm afraid
15:49:17 <bswartz> please register issues with that patch in gerrit if you have any
15:49:20 <bswartz> moving on...
15:49:50 <bswartz> #topic tempest plugin
15:49:57 <bswartz> #link https://blueprints.launchpad.net/manila/+spec/tempest-plugin-interface
15:50:12 <bswartz> #link https://review.openstack.org/#/c/201955/
15:50:28 <bswartz> mkoderer: you here?
15:50:43 <bswartz> I've been trying to get this one to pass gate
15:51:29 <bswartz> the silence is really loud on this one
15:51:43 <bswartz> I'll assume no discussion is needed and we'll try to keep it moving
15:51:47 <cknight> bswartz: I don't understand the benefit of this one.
15:51:51 <bswartz> please review it if you have issues
15:52:11 <bswartz> #topic Add Windows SMB share support
15:52:15 <vponomaryov> cknight: benefit of having tempest plugin?
15:52:19 <bswartz> #link https://blueprints.launchpad.net/manila/+spec/windows-smb-support
15:52:21 <cknight> vponomaryov: yes
15:52:33 <bswartz> #link https://review.openstack.org/#/c/200154/
15:52:41 <vponomaryov> cknight: clear interface and no hacking on tempest
15:52:42 <cknight> bswartz: The Windows driver has been reviewed and is ready, we've just been waiting on CI voting.
15:52:49 <bswartz> this hasn't been through the check pipeline since the gate breakage
15:53:05 <cknight> vponomaryov: OK, I'll defer to your Tempest expertise, then.
15:53:07 <bswartz> I think it's ready but lpetrut might need to rebase it
15:53:14 <vponomaryov> cknight:  +1, waiting for CI reporting that it is able to create shares in general
15:53:47 <bswartz> any discussion on new Windows SMB driver
15:54:10 <vponomaryov> bswartz: where is image for it?
15:54:25 <vponomaryov> lpetrut?
15:54:33 <bswartz> this driver has CI, although it's a little funky at the moment
15:54:46 <bswartz> the reporting format is garbled, but it's clearly running
15:55:27 <bswartz> vponomaryov: raise your issues in gerrit please
15:55:39 <bswartz> #topic Consistency groups in NetApp cDOT drivers
15:55:43 <cknight> bswartz: This one goes hand-in-hand with CGs, and it's been tested thoroughly with akerr's CG Tempest tests.  It was used as a model for the generic driver CG patch.
15:56:03 <cknight> bswartz: Shouldn't be controversial  ;-)
15:56:21 <bswartz> yes hopefully this should be a no-brainer assuming the CG core work is fine
15:56:35 <bswartz> also it can serve as a model for others implementing CGs
15:56:58 <bswartz> although if anyone has issues raise them in gerrit
15:57:06 <bswartz> #topic (last one) GlusterFS
15:57:13 <bswartz> this has a large number of patches
15:57:26 <bswartz> #link
15:57:28 <cknight> bswartz: Yes, and limited reviews on some of them.
15:57:29 <bswartz> #link https://blueprints.launchpad.net/manila/+spec/modular-glusterfs-share-layouts
15:57:44 <cknight> csaba: Is this an all-or-nothing thing?
15:57:50 <bswartz> csaba: does these ALL need to go in or can we start merging from the root?
15:57:56 <bswartz> lol same question
15:58:12 <csaba> cknight: well the point of the whole series is the last two patches
15:58:23 <bswartz> okay
15:58:43 <bswartz> well splitting it up for the reviewer's benefit is appreciated
15:59:01 <bswartz> I guess we'll ask reviewers to review the whole chain though and workflow backwards
15:59:08 <cknight> bswartz: The code seems OK, although there are some unit test gaps in exception paths I'd like to see covered.
15:59:23 <csaba> cknight: coverage is now at ~100%
15:59:33 <cknight> csaba: Thanks, I'll look again.
15:59:40 <bswartz> csaba: have you rebased on the gate fix?
15:59:49 <bswartz> gah we're out of time!
15:59:57 <bswartz> we need to discuss bugs
15:59:58 <csaba> bswartz: rebased yesterday over the patch you inidcated
16:00:05 <csaba> isthat the same as said today?
16:00:08 <bswartz> please come over to the #openstack-manila channel to discuss bugs
16:00:19 <bswartz> #endmeeting