15:01:35 <bswartz> #startmeeting manila
15:01:38 <openstack> Meeting started Thu Oct  1 15:01:35 2015 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:40 <toabctl> hi
15:01:43 <openstack> The meeting name has been set to 'manila'
15:01:43 <bswartz> hello
15:01:45 <ganso> hello
15:01:48 <cknight> Hi
15:01:49 <cfouts> hi
15:01:51 <sbjorn> hi
15:01:52 <markstur> hi
15:01:53 <csaba> hi
15:01:55 <Zhongjun> hello
15:01:55 <vponomaryov> hello
15:01:58 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:02:12 <u_glide> hello
15:02:13 <xyang1> Hi
15:02:49 <bswartz> xyang1: ping me after the meeting I just remembered I had a question for you
15:02:57 <xyang1> Sure
15:02:59 <bswartz> #topic Liberty RC2 status
15:03:08 <bswartz> errr
15:03:12 <bswartz> #topic Liberty RC2 status
15:03:35 <bswartz> so first of all thanks to those of you who have downloaded and tested RC1 and found bugs
15:03:52 <bswartz> and also thanks for fixing bugs
15:03:57 <bswartz> #link https://launchpad.net/manila/+milestone/liberty-rc2
15:04:05 <bswartz> #link https://review.openstack.org/#/q/project:openstack/manila+branch:stable/liberty,n,z
15:04:12 <bswartz> this is what we're targeted for RC2
15:04:48 <bswartz> it includes all the bugs which were tagged and merged in master by yesterday
15:05:34 <bswartz> hopefully it will be released by later today
15:05:39 <bswartz> I don't expect there to be an RC3
15:06:06 <bswartz> we would only do RC3 if we found a truly critical bug that had to be fixed before release
15:06:39 <bswartz> so for now we just have to struggle with out unstable gate and get the remaining backports merged
15:06:48 <bswartz> s/out/our/
15:07:24 <bswartz> fixing the unstable gate is top priority btw -- we're trying multiple solutions
15:07:30 <bswartz> but that's a different topic
15:07:46 <bswartz> #topic Mitaka Design Summit
15:08:00 <bswartz> #link https://etherpad.openstack.org/p/manila-mitaka-summit-topics
15:08:08 <bswartz> This is a reminder to propose your topics
15:08:34 * bswartz kicks himself for not proposing his own yet
15:09:01 <bswartz> we may not get another week before we have to decide on the agenda
15:09:33 <bswartz> so consider this your last chance to propose summit topics
15:09:39 <cfouts> another working session should be DR?
15:09:40 <bswartz> I'll propose mine today
15:10:01 <bswartz> cfouts: you mean DR 2.0?
15:10:08 <cfouts> sure :)
15:10:36 <bswartz> yeah we will want to talk about that for sure
15:11:01 <bswartz> the question will be whether it gets a whole session or if we cover it on Friday during the sprint
15:11:42 <bswartz> any questions about design summit?
15:12:05 <bswartz> quite a few people have let me know that they're coming so hopefully we'll have productive discussions
15:12:28 <bswartz> #topic Vendor driver docs
15:12:35 <bswartz> #link https://github.com/openstack/manila/blob/master/doc/source/devref/share_back_ends_feature_support_mapping.rst
15:13:32 <bswartz> csaba, chen12, markstur, diemt: ^ you haven't updated this yet
15:13:50 <bswartz> unless there's a patchset in gerrit I haven't seen yet
15:14:02 <markstur> on my todo list
15:14:07 <markstur> sorry
15:14:27 <bswartz> okay I'll be sending out nastygrams today :-)
15:14:59 <bswartz> some people are actually looking for a compatibility matrix for driver features and this is the table we're using
15:15:32 <bswartz> #topic open discussion
15:15:37 <bswartz> okay that's all I had today
15:15:48 <markstur> There is driver doc in the config-ref now too.  It isn't completely done, but it is merged.  https://review.openstack.org/#/c/224362/
15:15:51 <bswartz> it's been busy with the RC
15:16:08 <cknight> bswartz: Chuck wanted to talk about client versioning.
15:16:09 <cfouts> I'd like to talk about nova style microversion
15:16:10 <markstur> Driver owners should look at their sections and enter bugs, fixes, etc.
15:16:17 <bswartz> markstur: awesome!
15:16:36 <cfouts> https://review.openstack.org/#/c/229142/
15:16:39 <markstur> I'm hoping doc folks will help fix, but everyone should check it out.
15:16:59 <bswartz> cfouts: go ahead
15:17:03 <cfouts> I submitted the above patch as WIP
15:17:17 <xyang1> markstur: nearly 8000 lines!
15:17:19 <cfouts> the 'latest' version support was stripped out
15:17:31 <cfouts> xyang1: that is mine :)  I'll explain
15:17:45 <xyang1> Ok:)
15:18:06 <cfouts> it fails back automatically to support non-microversion servers such as Kilo
15:18:24 <cfouts> and loads the v1 client from the commit indicated in the message at https://review.openstack.org/#/c/229142/
15:18:39 <cfouts> otherwise it loads the v2 client which is the latest client code
15:18:55 <cfouts> open to suggestions on how not to have that much duplicate code
15:19:45 <cfouts> The diagram in the same commit message has been useful in discussing what versions the client will work with and when it will just bail
15:19:54 <cknight> cfouts: The v1 code is frozen, and the duplication means we can cleanly remove it when it's time to do that.
15:20:08 <cknight> cfouts: +1 for the ASCII art in the commit message
15:20:18 <cfouts> yes, when the community decides we can deprecate and then remove v1
15:20:20 <bswartz> yeah nice ascii art
15:20:42 <cfouts> the other major feature is using Nova's @wraps annotation on shell commands
15:20:44 <bswartz> cfouts: was it not possible to avoid duplication of the client code?
15:21:25 <cfouts> bswartz: there probably is a way to move more of the code into common
15:21:45 <bswartz> my only concern here, aside from the very large patch, is that if we end up with 2 copies of stuff we might need to fix bugs in 2 places until we finally remove v1
15:21:48 <cfouts> the layer below the multiple client.py and shell.py files
15:22:36 <cfouts> okay, I'll see if there is a clean and maintainable way to do that. again would welcome suggestions.
15:22:50 <bswartz> but this appears to do what I think is the right thing
15:23:05 <cfouts> would like feedback from community as well
15:23:38 <toabctl> what about droping v1 code in the client? people who need it can install older client version via pip
15:23:45 <bswartz> the client should use the newest API version that both it and the server understands, and if the server is no mutually supported version, it should fail
15:24:22 <u_glide> cfouts: why we cannot use different methods for different API when needed?
15:24:37 <bswartz> toabctl: the downside to that approach is that it becomes very hard to write a client that works with both kilo and some future version of Manila that has dropped v1
15:24:39 <u_glide> u_glide: instead of copypasting all client and unit tests
15:24:59 <cfouts> u_glide: @wraps annotation gives you the ability to have multiple commands.
15:25:25 <bswartz> the goal here was to allow clients applications to support a range of servers versions, especially if the particular APIs the client uses don't change
15:25:29 <cfouts> u_glide: @wraps lets you supply the supported version and have multiple do_list commands for instance
15:25:44 <u_glide> cfouts: Why haven't use @wraps in your commit then? :)
15:25:55 <toabctl> bswartz: true
15:26:17 <cfouts> u_glide: I have some things to fix so I can push up an example :)
15:27:19 <cfouts> the only other thing to mention is that Cinder is looking into doing microversions and people are looking to similate what Nova did
15:27:28 <cfouts> so I think we are on the right track
15:27:48 <cknight> cfouts: +1
15:27:59 <cknight> Anyone else disagree?
15:28:40 <bswartz> I should point out that one possible area of disagreement is about to what extent backwards-compatibility-breaking changes are allowed
15:29:00 <cknight> I like that fact that we can add new stuff to the client and not worry about breaking v1 support because the code is cleanly segregated.
15:29:04 <bswartz> from what I understand, nova doesn't allow them, even if they're properly microversioned so they could be done safely
15:30:40 <bswartz> I feel that microversions should be used as a mechanism to make whatever improvements we feel are necessary to the API, trying to avoid breaking changes, but using microversions to break things safely where there is no other option
15:31:01 <u_glide> cknight: why don't use liberty version of manilaclient then?
15:31:25 <u_glide> or kilo version for older backends
15:31:39 <bswartz> u_glide: you can't install both versions at the same time
15:31:41 <cknight> u_glide: It's then harder to build an application that uses old & new clients.
15:32:10 <toabctl> bswartz: you can i venvs but then you need to switch depending on which version you want to use.
15:32:19 <toabctl> /i/in/
15:32:47 <bswartz> yeah
15:33:07 <bswartz> I think it's better to have a single client that knows how to talk to both old and new things -- that's what nova has done
15:33:34 <toabctl> I agree. we should mark v1 as deprecated in the client but still have it there
15:33:40 <vponomaryov> bswartz: +1
15:34:25 <u_glide> but novaclient doesn't have copypaste :)
15:34:39 <cfouts> we can have the client display a deprecation warning as well
15:34:55 <bswartz> yes the question that's in my mind is whether we can support both without duplicate code
15:35:10 <cknight> u_glide: It wasn't quite copypaste.  Chuck grabbed the v1 code from before the introduction of microversions.
15:35:53 <cknight> bswartz: There is some code, like the HTTPClient, that can be moved to common.
15:36:17 <cknight> bswartz: But deduplicating some other things would make it harder to remove v1 later.
15:36:32 <bswartz> that's true
15:36:42 <bswartz> we don't want to make removal of v1 a difficult thing
15:37:28 <cknight> bswartz: I'm OK with some duplication if it means removing v1 is as quick and clean as removing a driver :-P
15:37:53 <cfouts> most of the *Manager code can be placed in common
15:38:03 <u_glide> why we cannot do what nova do with wraps https://github.com/openstack/python-novaclient/blob/39739158b0cf10a775fd3899e35df7f53b4c9336/novaclient/v2/services.py#L52 ?
15:38:06 <cfouts> and the v1/ v2/ files can import the managers
15:38:31 <cfouts> u_glide: that support is in there now
15:38:46 <cfouts> u_glide: but it only works for servers that support microversions
15:39:48 <toabctl> cknight: +1 for the deduplicating thing
15:40:46 <toabctl> question is if we expect a lot of bug fixes for the v1 code
15:41:33 <cknight> toabctl: Good question.  I'd be surprised if that were true.
15:41:56 <bswartz> my concern would be that if we found a bug we might only fix it in v2 even if v1 were also affected by the same bug
15:42:29 <vponomaryov> bswartz: making people migrate to v2?
15:42:32 <bswartz> it would be tough for reviewers to ensure that never happened
15:43:04 <bswartz> vponomaryov: we want people to migrate to v2 but users of the client may have valid reasons for wanting to continue to support kilo
15:43:24 <vponomaryov> bswartz: then bugs should be fixed in both versions
15:43:36 <u_glide> vponomaryov: +1
15:43:42 <bswartz> only if we duplicate the code and make 1 bug into 2 bugs
15:43:45 <toabctl> vponomaryov: +1
15:44:01 <bswartz> if we avoid duplicating the code the there would only be 1 bug to fix
15:44:43 <toabctl> about what time frame are we talking? when do we expect to remove v1 ?
15:45:12 <vponomaryov> toabctl: other project have idea to keep API deprecated at least for three releases
15:45:21 <vponomaryov> s/project/projects/
15:45:31 <bswartz> toabctl: deprecation of v1 on the server side and deprecation of v1 on the client side would be completely separate decisions
15:45:45 <toabctl> bswartz: sure. I'm talking just about the client side.
15:46:02 <bswartz> we could choose to continue v1 support in the client forever, even if we aggressively remove it from the server
15:46:29 <bswartz> that decision would be based on the cost of maintenance vs. the value of continuing to support kilo
15:47:19 <vponomaryov> bswartz: +1 for keeping it in client
15:47:43 <bswartz> okay I think there's general agreement on this subject
15:47:56 <bswartz> please add review comments on cfouts' patch
15:48:03 <bswartz> any other topics before we close for today?
15:48:18 <bswartz> nastygram about the feature table already sent
15:48:34 * bswartz goes to propose topics in etherpad
15:48:37 <bswartz> thanks all
15:48:42 <vponomaryov> thanks
15:48:43 <toabctl> thanks. bye
15:48:49 <bswartz> #endmeeting