15:01:27 <bswartz> #startmeeting manila
15:01:27 <openstack> Meeting started Thu Sep 24 15:01:27 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:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:30 <bswartz> hello all
15:01:31 <cknight> Hi
15:01:31 <openstack> The meeting name has been set to 'manila'
15:01:34 <toabctl> hi
15:01:41 <xyang1> Hi
15:01:42 <zhongjun> hi
15:01:43 <rraja> hi
15:01:47 <vponomaryov> hello
15:01:49 <csaba> hi
15:01:53 <xyang1> Who is OpenStack?
15:01:55 <u_glide1> hi
15:02:02 <vponomaryov> xyang1: ище
15:02:05 <vponomaryov> xyang1: bot
15:02:10 <xyang1> :)
15:02:11 <kaisers> hi
15:02:27 <bswartz> markstur: you able to join?
15:02:36 <dustins> \o
15:02:53 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:02:58 <dustins> xyang1: I think it's a bot that logs the channel?
15:02:58 <bswartz> we've got a lot to cover today
15:03:06 <bswartz> I'll try to go fast
15:03:17 <bswartz> #topic 3rd-party CI status
15:03:36 <bswartz> as of this week, quobyte and glusterfs started passing
15:03:43 <lpabon> sweet
15:03:48 <toabctl> great
15:03:50 <bswartz> and all of the other ones have been passing more or less
15:03:54 <kaisers> (Thanks to vponomaryov for Quobyte !!!!)
15:03:55 <dustins> woo
15:04:04 <bswartz> so I don't think we need to discuss removal of any more drivers
15:04:23 <bswartz> yes special thanks to vponomaryov for helping debug CI issues
15:04:25 <vponomaryov> bswartz: GPFS come back?
15:04:41 <bswartz> last I heard was the guarangt was close to getting GPFS working
15:04:54 <bswartz> but it's not reporting yet
15:04:59 <bswartz> so we will see
15:05:09 <rraja> thanks vponomaryov and cknight for your help.
15:05:16 <tbarron> hhi
15:05:28 <toabctl> what about HDS SOP ? is there any progress so the driver could be readded?
15:05:54 <bswartz> jasonsb acknowledged that HDS was not working on CI for that driver
15:06:19 <toabctl> ok
15:06:23 <cFouts> hi
15:06:23 <bswartz> if HDS changes their mind I'll be happy to bring that driver back -- I think they decided that manila support was not a priority for them
15:07:07 <bswartz> so THANKS to all the vendors that worked on CI this release, I know it was a lot of work for some
15:07:29 <bswartz> In Mitaka, we will be looking at increasing the scope of what's tested by CI, and starting to define minimum requirements
15:07:49 <vponomaryov> early, late Mitaka?
15:07:51 <bswartz> I think it's a huge achievement just to get the systems all up and running in a single release though -- cinder took longer
15:08:04 <bswartz> vponomaryov: let's talk about it in coming weeks
15:08:11 <xyang1> bswartz: can that be decided at the summit
15:08:27 <bswartz> xyang1: yeah it would be a good disucssion topic for the summit
15:08:31 <bswartz> let's move on though
15:08:40 <bswartz> #topic Liberty RC status
15:08:51 <bswartz> Liberty RC1 was released on Tuesday!
15:09:10 <bswartz> thanks to all the reviewers for helping with that, and thanks for getting the bugs squashed
15:09:34 <bswartz> Everyone should be testing RC1 aggressively to see if there are any remaining bugs
15:09:44 <bswartz> I know a few have been found already
15:09:51 <vponomaryov> bswartz: we already have some for backporting
15:10:17 <bswartz> if you find a bug that you think need to be fixed in Liberty, please TAG your bug in LP with "liberty-rc-potential"
15:10:33 <bswartz> and make sure to get the fix for the bug merged into master
15:10:55 <bswartz> we will look at all the tagged bugs with merged fixes later this week and decide if there will be an RC2 and if so, what should go in it
15:11:00 <xyang1> Since mitaka is open, Does that mean we can start to merge new features now, or still only bug fix can be merged
15:11:27 <vponomaryov> xyang1: mitaka is open
15:11:34 <bswartz> xyang1: new feature can merge now, but I would ask core reviewers to avoid merging anything that might make backports to liberty difficult, until after the Oct 15 release
15:11:45 <xyang1> bswartz: ok
15:11:47 <bswartz> so big giant new features should wait
15:12:07 <bswartz> priority right now is liberty quality
15:12:29 <bswartz> #topic Support for QoS in Manila
15:12:37 <bswartz> zhongjun2: you're up
15:12:59 <zhongjun> ok
15:12:59 <zhongjun> I draft the QoS design in https://wiki.openstack.org/wiki/Manila/QoS.
15:13:01 <bswartz> is zhongjun2 and zhongjun different people?
15:13:32 <zhongjun> one people
15:13:34 <kaisers> perhaps same person but different clients?
15:13:44 <bswartz> zhongjun: hello!
15:13:47 <zhongjun> yes
15:13:54 <bswartz> that spec looks pretty nice and detailed
15:14:02 <cknight> zhongjun: Is your intention to remain consistent with the Cinder QoS implementation?
15:14:17 <zhongjun> The goal is to add an interface so that Manila admins can use to set share QoS specification
15:14:26 <zhongjun> (IOPS, bandwidth, Latency, priority and other vendor specified attributes),
15:14:26 <zhongjun> which can be enforced in nova or on Manila back-end or both;
15:14:35 <bswartz> zhongjun: do you plan to have working code before the design summit, or did you want to discuss this at the design summit before doing the implementation?
15:14:48 <zhongjun> I am not sure it is ok about this QoS design.
15:15:13 <bswartz> zhongjun: enforcement of QoS policies by nova won't work
15:15:34 <bswartz> zhongjun: shares don't go through the hypervisor, they're access directly by guests
15:15:41 <bswartz> accessed
15:15:55 <bswartz> however QoS enforcement on the backends is a valuable feature
15:15:55 <zhongjun> partial consistency.
15:16:56 <bswartz> zhongjun: anything you want decided today? or are you just raising awareness of this feature?
15:17:40 <cknight> zhongjun: Your spec mentions modifying API extensions.  We are planning to move all extensions into core during Mitaka, so this would need to be core API work.
15:17:53 <bswartz> cknight: +!
15:18:05 <bswartz> +1
15:18:36 <zhongjun> Yes, I want to discuss this at the design summit before doing the implementation
15:18:41 <bswartz> okay
15:18:54 <cknight> zhongjun: And for those of us familiar with Cinder QoS, it would help if you spelled out any differences, please.
15:18:56 <bswartz> well I think it's a good idea, we'll cover design summit later in the agenda
15:19:03 <bswartz> #topic Reminder for backend driver maintainers to update feature support table
15:19:15 <bswartz> #link http://docs.openstack.org/developer/manila/devref/share_back_ends_feature_support_mapping.html
15:19:27 <bswartz> toabctl: anything you wanted to say about this?
15:19:47 <toabctl> I added it. there are still a lot of questionmarks in the tables and it's a friendly reminder to the driver maintainers to fill the table
15:20:10 <xyang1> Something came up during review on this
15:20:14 <toabctl> I think the table is very useful if we can fill it with the missing infos. nothing more to say I think
15:20:20 <bswartz> toabctl: we may need to start pinging driver maintainers individually
15:20:34 <vponomaryov> xyang1: you mean "planned" thing?
15:20:37 <bswartz> but hopefully this reminder will get everyone to go push their updates
15:20:44 <xyang1> It has M for future planning, cknight pointed out it is confusing
15:20:47 <xyang1> Yes
15:21:03 <bswartz> oh yeah I see that
15:21:17 <toabctl> yes. we should only add things that *are* implemented
15:21:18 <zhongjun> I added it.
15:21:18 <bswartz> I agree we shouldn't reflect "planned" features in this table
15:21:25 <cknight> xyang1: My concern was that stuff happens, so people should be cautious about promising things before they land.
15:21:39 <xyang1> cknight: agree
15:21:58 <bswartz> #agreed the supported feature table should only include currently supported features, not future
15:22:12 <xyang1> If we really want to add M, we should say "planned for M"
15:22:24 <bswartz> xyang1: no, just leave it out, and change i when it's merged
15:22:29 <cknight> bswartz: OK, I can tweak the table description to remove the future language.
15:22:35 <xyang1> bswartz: sure
15:22:47 <cknight> bswartz: I can push that up immediately.
15:22:56 <bswartz> it doesn't offer much value to merge a change that says "we plan to do this" -- vendors can announce their plans by posting blueprint on LP and such
15:23:10 <kaisers> i have a change in review on that, will remove the planned markers, then.
15:23:45 <bswartz> by next week if there are still ??? in any rows I'll ping the maintainers of the drivers
15:24:05 <bswartz> let's move on
15:24:13 <bswartz> #topic Regression when using NetApp - license issue with netapp_lib
15:24:23 <bswartz> toabctl: this is you again
15:24:27 <xyang1> bswartz: isilon is working on it too
15:24:29 <bswartz> #link https://bugs.launchpad.net/cinder/+bug/1499334
15:24:30 <openstack> Launchpad bug 1499334 in Manila "Regression: Proprietary code needed to use NetApp with Cinder and Manila" [Undecided,In progress] - Assigned to Thomas Bechtold (toabctl)
15:24:39 <toabctl> also mine. so I tried to use netapp this morning and recognized that a proprietary lib is now needed
15:24:53 <toabctl> that's a regression for distributions and depoyers compared to the Kilo status
15:25:17 <bswartz> to be clear, what's needed is an open source lib from pypi with a proprietary license
15:25:20 <toabctl> the thing is that there is already working code released under the Apache-2.0 license
15:25:50 <toabctl> so I don't see any need to require that lib
15:26:02 <bswartz> I've informed the appropriate people at netapp about the bug
15:26:17 <u_glide1> bswartz: Is it possible to change lib license?
15:26:38 <bswartz> u_glide1: I don't have an answer for that
15:26:50 <xyang1> bswartz: i thought pypi requires apache license?
15:26:55 <toabctl> I know that other vendors are doing the same but in this case we already have the apache-2.0 licensed code. that's why i'm raising the issue
15:27:05 <cknight> xyang1: pypi accepts any license
15:27:09 <bswartz> xyang1: pypi lets you specify the license -- there are tons of different licenses on that site
15:27:19 <xyang1> cknight: bswartz ok
15:28:15 <cknight> toabctl: We understand your concern, and we've raised it again with the people that made us do it.  In the meantime, we'd appreciate the core team not merging the revert patch.
15:28:44 <vponomaryov> cknight: how soon answer is expected?
15:28:46 <bswartz> what toabctl says is true, but as a NetApp employee I'm recusing myself from any decisions regarding that bug to avoid a conflict of interest
15:29:01 <toabctl> cknight: hm. so my proposal would be to revert it. it's an open source project. but you can add a patch to check if the lib is there and if it is, use it.
15:29:37 <cknight> toabctl: How would that help?  We do check for the library.
15:29:57 <toabctl> cknight: I could use a NetApp without downloading some extra lib
15:30:24 <toabctl> cknight: that simplifies a lot for distributors . and I guess also for deployers
15:31:02 <cknight> toabctl: Understood completely.  We're trying to get some resolution from the legal team.  (Cue the lawyer jokes.)
15:31:34 <toabctl> cknight: I understand that it's less work if you use a lib for the stuff needed in cinder and manila.
15:31:46 <bswartz> anyone have a different opinion to offer?
15:31:53 <bswartz> I'm not sure we can reach any decision on this topic
15:32:10 <toabctl> bswartz: well. if we don't have a -1 and 2 +2 we have one...
15:32:26 <vponomaryov> bswartz: I agree that we have regression and we can not revert back, but implement possibility to chose what to use
15:32:43 <toabctl> an without speaking with my SUSE hat, I think this is open soucre and we should try to avoid such changes.
15:32:53 <xyang1> Not sure if I follow this completely,  but you may be able to make a small change in your driver to get around it
15:33:08 <bswartz> toabctl: I think netapp's opionon on the subject is clear -- they pushed the patch that introduced the dependency
15:33:24 <xyang1> I can find some link and send to cknight to see if it helps
15:34:36 <kaisers> Do linux distributors have a general issue with this that prevents distribution in this setup? I'm not too familiar with how a proprietary license in that lib affects that overall process.
15:35:06 <bswartz> hopefully we'll get an official response from netapp soon, but we can let the discussion continue in the gerrit change
15:35:11 <toabctl> bswartz: I wonder if it would help if I would create a netapp_lib_foobar with the code from manila and propose that to use for cinder and manila? would you guys then work on that? or would you still try to push the proprietary thingy?
15:35:53 <bswartz> toabctl: again I have no answer for that -- it's not so much a technical problem as a legal one and that's not my area
15:36:01 <toabctl> ok. then I hope to get enough +2 but I wouldn't merge it yet. but a decision before the final release would be good imho
15:36:08 <toabctl> bswartz: ok.
15:36:14 <bswartz> let's move on
15:36:16 <kaisers> ok, let's continue that in the change
15:36:23 <bswartz> #topic Mitaka Design Summit
15:36:32 <bswartz> #link https://etherpad.openstack.org/p/manila-mitaka-summit-topics
15:36:48 <bswartz> so it's time to collect proposals for topics
15:36:56 <kaisers> toabctl: Perhaps add a bit more detail on what the issue is in distribution to that change desc/comments
15:37:07 <bswartz> I created an empty etherpad today so you can start to propose things
15:37:20 <bswartz> I have my own list that I'll add when I have some time
15:37:38 <bswartz> I'm actually not sure what the deadline is to decide on topics
15:37:51 <bswartz> #action bswartz find out the deadline for summit session topics
15:38:20 <bswartz> hopefully many of you have already thought of things you'd like to propose
15:38:36 <bswartz> let's get them written down so we can start to discuss them in coming weeks
15:38:49 <bswartz> any questions on Mitaka design summit?
15:38:59 <vponomaryov> alos, please, sign yourself writing topic
15:39:06 <bswartz> oh yeah
15:39:16 <bswartz> add IRC nicks to topics so we know who proposed what
15:40:26 <bswartz> okay
15:40:35 <bswartz> #topic Vendor driver docs
15:41:00 <bswartz> so I've been asked a few times in the last week, what about docs in the manila tree and the stable/liberty branch
15:41:46 <bswartz> the fact that we have some user-facing docs in our manila tree is an accident of history and not what we prefer going forward
15:42:16 <vponomaryov> bswartz: you propose to remove them?
15:42:23 <bswartz> vendors are welcome to merge docs changes into the existing docs for Mitaka, but we're in the process of moving all of our user-facing docs to the correct places on docs.openstack.org
15:42:40 <bswartz> vponomaryov: over the next month or so, yes
15:43:05 <bswartz> right now some of the docs being added to openstack-manuals are not merged yet, so it's hard for vendors to know where to make changes
15:43:30 <bswartz> until the upstream docs are sorted out, it's find to keep merging things to the manila docs directory
15:43:58 <bswartz> the main point I wanted to make is that we don't backport docs to liberty -- the theory is that users should read the latest docs
15:44:36 <bswartz> and after we finish cleaning up the docs and moving everything, the only docs that should live in-tree are the developer docs
15:45:01 <bswartz> I hope that clears up some confusion
15:45:31 <cknight> bswartz: Here's the tweak to the driver doc that removes the 'future' language:  https://review.openstack.org/#/c/227385/
15:45:48 <bswartz> and just a reminder, we've made a ton of progress on this: https://etherpad.openstack.org/p/manila-liberty-documentation-sprint
15:46:14 <bswartz> some docs changes are merged and some are in review
15:46:37 <bswartz> cknight: thx
15:47:04 <bswartz> #topic open discussion
15:47:16 <bswartz> anyone have anything else for today?
15:47:48 <bswartz> wow, we might get done early
15:48:19 <bswartz> okay thanks everyone
15:48:34 <bswartz> #endmeeting