14:59:59 <bswartz> #startmeeting manila
14:59:59 <openstack> Meeting started Thu Apr 20 14:59:59 2017 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:02 <openstack> The meeting name has been set to 'manila'
15:00:07 <bswartz> oops 1 second too early
15:00:10 <bswartz> hello all
15:00:16 <vponomaryov> Hello
15:00:19 <vkmc> hi!
15:00:19 <markstur> hi
15:00:22 <rraja> hi
15:00:23 <ganso> hello
15:00:27 <xyang1> Hi
15:00:28 <toabctl> hi
15:00:34 <jungleboyj> o/
15:00:35 <dustins> \o
15:00:42 <arnewiebalck> hi
15:00:46 <tommylikehu> hey
15:00:47 <zhongjun> hi
15:00:50 <tbarron> hi
15:00:53 <bswartz> #topic announcements
15:01:24 <bswartz> so we decided to grant extensions to 4 specs last week, with a new deadline of today
15:01:45 <bswartz> the only agenda items for this meeting are those 4 specs
15:02:00 <bswartz> none of them merged yet but some of them did make good progress
15:02:16 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:02:24 <bswartz> #topic Ensure shares
15:02:30 <bswartz> #link https://review.openstack.org/#/c/446494/
15:02:46 <bswartz> so first up, ensure shares
15:02:47 <gouthamr> o/
15:03:02 <bswartz> this one is the most important to me, and the one I've been focusing on
15:03:23 <bswartz> we held a teleconference tuesday morning to discuss changes with interested parties
15:03:42 <bswartz> and we agreed that I would become a co-author on the spec and work on it with zhongjun
15:04:18 <bswartz> the current proposal is somewhat different that what was proposed last week, and still somewhat different than what we agreed to on the tuesday meeting
15:04:25 <zhongjun> thanks
15:04:53 <bswartz> the tuesday meeting mostly accomplished the team agreeing what problem we were trying to solve, and agreeing in principle how to solve it
15:05:30 <bswartz> after writing up what we agreed to, I realized we could refine it further and give drivers more control, plus avoid gratuitous ensure_share calls
15:06:04 <bswartz> we also agreed that, despite our original assumptions, there are no cases when we want to ensure some subset of the shares on a backend
15:06:09 <bswartz> it's always all or nothing
15:06:33 <vponomaryov> bswartz: all per backend you mean?
15:06:42 <bswartz> yes all or nothing per backend
15:07:05 <bswartz> because the work is done by the drivers, there's no way to go cross-backend with ensure share
15:07:27 <bswartz> and there's no reason to either
15:07:48 <bswartz> so anyways, I think this spec is basically ready
15:07:56 <bswartz> we could refine it and add more details if needed
15:08:11 <bswartz> but I feel like we're past all the major design decisions
15:08:35 <bswartz> we can discuss it here, or decide to merge it, or give people some more time for more reviews before it merges
15:08:51 <bswartz> I dunno if the rest of today is enough time, but I hope it is
15:09:02 <vponomaryov> bswartz: at least rest of the day would help
15:09:14 <vponomaryov> bswartz: last PS was just uploaded
15:09:14 <bswartz> well we gave a 1 week extension
15:09:23 <bswartz> so that takes us to 23:59 today
15:09:31 <vponomaryov> how many hours from now?
15:09:44 <bswartz> about 8 (?) more hours
15:09:53 <vponomaryov> ok, ty
15:10:10 <bswartz> does anyone want to wait longer on this spec?
15:10:44 <bswartz> okay sounds like no
15:11:04 <bswartz> let's try to get final reviews done today and I'll be on top of responding to comments and updating if needed
15:11:09 <bswartz> let's move on
15:11:16 <gouthamr> +1
15:11:16 <bswartz> #topic Update shares
15:11:21 <bswartz> #link https://review.openstack.org/#/c/453553/
15:11:27 <zhongjun> +1
15:11:53 <bswartz> so this one got a bit of attention late last week, but not much this week
15:12:36 <bswartz> give the amount of focus on other specs, it's not surprising this didn't get as much attention
15:12:42 <zhongjun> This one have a  little change from ensure share spec.
15:13:09 <bswartz> I'm wondering if we should simply deprioritize this one and focus on the remaining ones
15:13:18 <gouthamr> there are a flurry of periodic calls already, and adding one more might not be good design
15:13:29 <bswartz> I'd like to invest in features that matter to people, and this one is definitely lowest on my list (of the remaining specs)
15:13:31 <gouthamr> can we see how ensure share goes and evaluate?
15:13:46 <zhongjun> It is based on ensure share spec, so it is not got a bit of attention
15:13:46 <vponomaryov> gouthamr: have you looked at "autosized/infinite"share spec?
15:14:19 <bswartz> vponomaryov: that's later in the agenda
15:14:19 <gouthamr> vponomaryov: not recently, but i know usage stats are expected to be updated periodically...
15:14:27 <bswartz> let's not cover that yet
15:15:11 <bswartz> I'm not in favor of merging update share today, we could decide to give it more time or push it out
15:16:03 <bswartz> zhongjun if you feel strongly about keeping this spec in pike please explain why it's necessary and ensure_shares isn't good enough
15:16:12 <zhongjun> bswartz: This one based on ensure share spec, since the ensure share has been merged, this one will not far from merge
15:17:02 <bswartz> zhongjun: I don't agree -- the use cases may be similar but the technical challenges are very different and the design needed to satisfy online updates is much more complex
15:17:16 <tbarron> if ensure_shares gets implemented early we could decide to reconsider it then.  I think there are tricky design issues that haven't been worked out yet even though there's lots of good ideas that have been started.
15:17:44 <bswartz> we covered that topic briefly in the tuesday meeting
15:18:11 <bswartz> periodic tasks are something really dislike
15:18:17 <tbarron> If we approve the spec as is then we will hash out those issues in code review and there's good chance of -2s.
15:18:30 <tbarron> if there isn't agreement on fundamental design.
15:19:50 <bswartz> I suppose I can imagine ways that this could be implemented efficiently
15:19:53 <zhongjun> bswartz:  yes, I also don't like periodic task, firstly  I try to add new API to implement it
15:19:58 <bswartz> but my guy tells me it won't be easy
15:20:08 <bswartz> s/guy/gut/
15:20:41 <markstur> did using a signal to kick off dynamic updates get rejected somewhere?
15:20:58 <bswartz> markstur: link?
15:21:29 <markstur> just thought we'd have dynamic config re-read using a kill signal like nova has discussed for a long time
15:21:39 <bswartz> I actually think a periodic task is the right user experience, but we have known issues with period tasks that should be sorted out before we add more uses of them
15:22:02 <jungleboyj> markstur:  Supposedly that is working for manila .
15:22:07 <bswartz> markstur: that was intended for reloading of conf files, not for updates of all of the shares on the backend
15:22:20 <jungleboyj> I haven't gotten it to work in test but I think that was because I was in devstack which is a 'special flower'.
15:22:30 <jungleboyj> bswartz:  ++
15:22:53 <bswartz> I guess I'm not opposed to this features and I'm sure we could sort out the issues eventually
15:23:01 <markstur> ok.  I was just thinking a conf change could kick off ensure-shares and some of this is overkill, but...
15:23:10 <bswartz> my main concern is focusing the team during the limited time we have
15:23:27 <markstur> given a clean state a conf listener would be better than a kill signal
15:23:42 <bswartz> markstur: you mean HUP signal
15:23:51 <bswartz> we're getting offtopic though
15:24:16 <markstur> so this spec isn't ready.  The question should be whether another extension makes sense
15:24:40 <markstur> "focusing the team" implies push to Q doesn't it?
15:24:46 <bswartz> I would be okay with giving it more time, but I in my mind this is less important than the other 2
15:25:04 <ganso> I like gouthamr's point that we could wait to see how ensure_shares will play out
15:25:11 <bswartz> I we could stack rank the specs I'd put this one at the bottom
15:25:34 <zhongjun> We could solve one more use case if we give this spec some time
15:25:35 <tbarron> ganso: that's a good iterative approach
15:25:37 <bswartz> honestly I don't care whether it goes into pike or queens as long as it doesn't distract from other pike stuff we care more about
15:26:14 <bswartz> the issue is that our process forces us to make a call at milestone-1 about specs being in or out
15:26:26 <bswartz> we can't postpone that decision under our current rules
15:26:52 <bswartz> (other than granting specific extensions, which is what we did here)
15:27:36 <bswartz> I'm going to resort to the vote feature, so we can make a call and move on
15:28:17 <bswartz> #startvote How should we handle update shares spec? more_time, push_to_queens
15:28:18 <openstack> Begin voting on: How should we handle update shares spec? Valid vote options are more_time, push_to_queens.
15:28:19 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
15:28:32 <bswartz> (sorry for long choices)
15:28:36 <tbarron> #vote push_to_queens
15:28:42 <bswartz> #vote push_to_queens
15:28:50 <markstur> #vote push_to_queens
15:28:54 <kaisers_> #vote #push_to_queens
15:28:55 <openstack> kaisers_: #push_to_queens is not a valid option. Valid options are more_time, push_to_queens.
15:29:01 <ganso> #vote #push_to_queens
15:29:01 <openstack> ganso: #push_to_queens is not a valid option. Valid options are more_time, push_to_queens.
15:29:04 <vponomaryov> #vote push_to_queens
15:29:07 <toabctl> #vote push_to_queens
15:29:09 <ganso> #vote push_to_queens
15:29:20 <dustins> #vote push_to_queens
15:29:24 <gouthamr> #vote push_to_queens
15:29:33 <kaisers_> #vote push_to_queens
15:29:35 <zhongjun> Ok, we could do it in next version
15:29:38 <bswartz> #endvote
15:29:38 <openstack> Voted on "How should we handle update shares spec?" Results are
15:29:39 <openstack> push_to_queens (9): bswartz, toabctl, markstur, ganso, gouthamr, kaisers_, vponomaryov, tbarron, dustins
15:29:44 <bswartz> wow we're unanimous
15:29:50 <bswartz> that was easier than I though
15:29:51 <markstur> I regret that this discourages folks from getting it ready during pike. I hope someone has some time to get it ready
15:30:08 <markstur> but it seems our spec process/etc does help us all focus
15:30:11 <bswartz> markstur: you make a good point but I have a response
15:30:34 <bswartz> I would strongly prefer it if new features were worked on ahead of a release rather than during a release
15:30:56 <bswartz> how great would it be to start the queens release with the code and spec for update shares already done
15:31:06 <markstur> +!
15:31:07 <tbarron> bswartz: +1000
15:31:09 <tommylikehu> +1
15:31:21 <bswartz> yes we're prioritizing other things, but that shouldn't discourage contributors for working on stuff for queens during like
15:31:26 <bswartz> s/like/pike/
15:31:30 * markstur typo let to +!, but that works!
15:31:31 * bswartz smh
15:31:47 <bswartz> okay we have 2 more important ones, let's move on
15:31:58 <bswartz> #topic Infinite shares
15:32:03 <bswartz> #link https://review.openstack.org/#/c/452097/
15:32:15 <tbarron> I don't think we have agreement on what an infinite or auto-sized share would be yet.
15:32:15 <tbarron> We do have agreement that it would require collecting usage per share and collecting usage per share.
15:32:15 <tbarron> And I think we have agreement that the need for collecting such usage:
15:32:15 <tbarron> (1) exists independently of infinite/auto-sized share (see arne's remarks in manila channel earlier today)
15:32:15 <tbarron> (2) would be a natural extension of vkmc's ceilometer integration work
15:32:17 <tbarron> (3) but we don't have a good scalable design for collecting usage yet
15:32:50 * tbarron shuts up now (for a minute at least)
15:33:02 <vponomaryov> (3) is the most critical
15:33:07 <bswartz> tbarron: we could handle this one similarly to what we did with ensure_share and schedule another meeting to hash out the details with interested parties
15:33:33 <tbarron> vponomaryov: +1000
15:33:39 <bswartz> assuming there's enough interest in pushing for this to get done in pike and we believe that the problems are tractable
15:33:52 <vponomaryov> and yes, should be split up to two - usage reporting is one spec and auto/infinite is second
15:34:41 <bswartz> so I apologize for not being familiar with this spec, but I have vague memories of the earlier discussions in austin about infinite (unlimited) shares
15:35:22 <bswartz> for my benefit, what's the purpose of tracking the size at all?
15:35:33 <vponomaryov> bswartz: to bill for usage, not quota
15:35:38 <bswartz> isn't unlimited supposed to mean unlimited
15:35:58 <bswartz> okay but we don't currently support usage or billing directly
15:35:58 <zhongjun> bswartz: yes, user will pay for usage
15:36:23 <markstur> isn't infinite supposed to mean infinite?
15:36:34 <bswartz> so we're assuming there's a mechanism to monitor the consumed space and report that to a billing tool?
15:36:44 <bswartz> would we ever want similar functionality for our limited shares?
15:36:45 <tbarron> there are as many ideas of what infinite share means as reviewers
15:36:54 <vponomaryov> bswartz: no, store it and update in our DB
15:37:04 <bswartz> markstur: nothing is really infinite
15:37:08 <tbarron> bswartz: we do want it, yes, see arne's remarks in channel today
15:37:09 <gouthamr> we're also expecting that administrators must be able to control the size of "infinite" shares...
15:37:31 <arnewiebalck> gouthamr: +1
15:37:43 <bswartz> gouthamr: why?
15:37:53 <zhongjun> bswartz: we could send it to ceilometor.. or something other tool
15:37:57 <tommylikehu> gouthamr, plus automatically
15:37:57 <gouthamr> resource starvation...
15:38:05 <markstur> bswartz: in theory infinite is infinite and nothing is something
15:38:12 <bswartz> if the adminsitrator is getting money from the user for the used space in the share, doesn't the administrator have an incentive to let the usage grow without bounds?
15:38:13 <markstur> but sorry for digressing
15:38:28 <gouthamr> markstur: :) are you loitering around the himalayas these days
15:38:33 <tbarron> bswartz: not if it uses up the pool
15:38:59 <markstur> gouthamr: :)
15:39:12 <jungleboyj> markstur:  Is there here to derail for fun.  ;-)
15:39:14 <bswartz> tbarron: a fully consumed pool is maximum profit for the provider assuming you're billing for usage
15:39:23 <vkmc> apart from billing, I think it would be useful to users to know how loaded are the shares they are administrating, that can help them to take actions
15:39:34 <tbarron> bswartz: not if other users discontinue service b/c they got starved
15:40:05 <vkmc> like, I don't know, resize the share because there is a lot of wasted resources
15:40:06 <bswartz> tbarron: in theory that would only happen if the admin wasn't fast enough to grow the pool as it filled up
15:40:13 <tbarron> bswartz: also, not all resource control is by chargeback, see CERN example in channel
15:40:15 <arnewiebalck> bswartz: not all deployments are for profit (and will hence simply grow if there is higher user demand)
15:40:24 <tbarron> bswartz: ack
15:40:32 <tbarron> ^^^ real world
15:40:36 <bswartz> thanks to disks being obscenely slow pieces of hardware, you usually have a warning when they approach full capacity
15:40:55 <tbarron> ^^^ real world, 3am
15:41:06 <bswartz> okay so arnewiebalck's use case is the more challenging case
15:41:46 <bswartz> there's no natural pressure to use storage efficiently because the consumers aren't charged, but the admin still wants to size the shares flexibly
15:42:30 <bswartz> tbarron: I used the weasel work "usually"
15:42:43 <bswartz> weasel word
15:43:00 <tbarron> bswartz: I'm always looking for weasel work.
15:43:11 <gouthamr> :D
15:43:19 <bswartz> okay so I don't feel like we're going to solve the technical problem during this meeting
15:43:21 * tbarron is hungry
15:43:32 <bswartz> and I also sense that there's interested in continuing to work on this
15:43:54 <vponomaryov> bswartz; yes, idea is interesting and useful, design not nailed yet
15:44:06 <bswartz> so I'm going to propose giving this spec some more time, and trying to schedule a specific meeting to get together and work through the issues here
15:44:07 <markstur> seems like an interesting spec to discuss, but not close to ready for code
15:44:10 <arnewiebalck> vponomaryov: +1, I think users will like this
15:44:26 <zhongjun> bswartz: +1
15:44:39 <bswartz> please rasie your hand if you want to be included in meetings about this spec
15:44:45 <bswartz> .o/
15:44:47 <gouthamr> +1
15:44:50 <vponomaryov> o/
15:44:53 <vkmc> +1
15:44:56 <arnewiebalck> o/
15:45:06 <gouthamr> rasie-ing my hand o/
15:45:06 <vkmc> o/ there, more graphical
15:45:14 <bswartz> friday morning is probably the best time, if people are available
15:45:20 <tbarron> +1
15:45:21 <ganso> o/
15:45:43 <zhongjun> +1
15:45:58 <tbarron> \o/
15:46:02 <bswartz> how about 1300 on friday?
15:46:09 <zhongjun> I am ok
15:46:10 <markstur> timezone?
15:46:12 <bswartz> does that not work for anyone?
15:46:15 <zhongjun> UTC
15:46:19 <bswartz> markstur UTC, always
15:46:29 <bswartz> UTC is the official timezone of openstack
15:46:30 <vponomaryov> works for me
15:46:37 <ganso> works for me
15:46:49 <gouthamr> okay, sadly got to bail out.. will be on a plane at 1300 UTC tomorrow..
15:46:51 <tbarron> i have a conflict 1300-1400
15:47:03 <bswartz> does 1400 work?
15:47:08 <tbarron> can do earlier or later
15:47:40 <bswartz> okay we don't have to use up this whole meeting with scheduling
15:47:51 <zhongjun> arnewiebalck: How about you?
15:47:53 <gouthamr> bswartz: i'll try catching up with the after-meeting brief
15:47:57 <bswartz> I'll contact interested parties after the meeting
15:48:08 <bswartz> I'd like to do 1300 or 1400 tomorrow just to get it done
15:48:17 <bswartz> otherwise we're looking at monday
15:48:25 <arnewiebalck> I’m fine with all discussed options.
15:48:46 <arnewiebalck> But prefer Friday over Monday :-D
15:48:50 <xyang1> bswartz: if it is 1400 tomorrow, I can join too
15:49:03 <bswartz> #agreed infinite share spec gets another week and we'll swarm on it to get the spec ironed out
15:49:15 <bswartz> #topic API filtering
15:49:22 <bswartz> #link https://review.openstack.org/#/c/447775/
15:49:46 <gouthamr> okay, about this tommylikehu and i discussed extensively last evening
15:49:51 <gouthamr> i've a couple of things to add
15:50:14 <bswartz> so last week we agreed that we would defer to cinder on the API interface details and only use the manila spec to cover the manila-specific implementation details
15:50:16 <gouthamr> 1) I misunderstood what the intent of the "generic" filtering spec on cinder's side until code showed up..
15:50:30 <tommylikehu> a couple ? I thought we only have one
15:50:43 <bswartz> but there are now concerns about the intent of the cinder spec
15:50:47 <gouthamr> cinder has an option to allow administrators to control filters
15:51:09 <gouthamr> now, they want to create an "allowable_filters" json file that can be tinkered and discovered over API "get me available filters"
15:51:44 <gouthamr> we neither have that option, nor do i think we signed up to that specific proposal
15:51:45 <bswartz> gouthamr: as I mentioned yesterday, I think that's bad API design
15:52:06 <bswartz> the cinder guys made a choice in the past which I don't agree with
15:52:27 <ganso> bswartz: only one?
15:52:37 <vponomaryov> ganso: ^_^
15:52:42 <bswartz> ganso: good point, lol
15:52:52 <tommylikehu> lol
15:52:55 <markstur> :)
15:53:04 <gouthamr> i agree... the point being we don't need to reference that specific spec anymore unless we want to misunderstand the work being proposed here
15:53:04 <zhongjun> haha
15:53:29 <gouthamr> we lack filtering in a "generic" way across our GET APIs... some of them have it: shares, snapshots, networks..
15:53:39 <gouthamr> maybe we can audit the rest and add them in one micro-version
15:53:40 <xyang1> bswartz: provide a list of things that you do agree with Cinder:)
15:53:43 <gouthamr> and document that
15:53:59 <bswartz> anyways the decision to implement filtering, but only if a server option is turned on, seems TOO configurable for me
15:54:11 <gouthamr> now 2) zhongjun and tommylikehu's main point on the spec was to introduce "contains" or "like" matching
15:54:17 <markstur> xyang1: :)
15:54:25 <xyang1> :)
15:54:27 <bswartz> sometimes API functionality needs to be modifiable for good reasons, we have examples of that
15:54:47 <gouthamr> policy
15:54:52 <bswartz> but what kinds of filtering is allowed? that's beyond the pale for me
15:55:15 <bswartz> filtering should be one of those things that's consistent across the board
15:55:22 <bswartz> it should just work
15:55:51 <gouthamr> hmmm, so zhongjun: i apologize for the mix up on my part.. i have some comments for you on the spec...
15:56:04 <tommylikehu> so gouthamr  suggests we should go back to two weeks ago and get back to the initialize propose.
15:56:20 <zhongjun> gouthamr: It doesn't matter, I will see it
15:56:47 <gouthamr> we'll get this in shape today..
15:56:54 <bswartz> gouthamr: does that mean not trying to harmonize our design with cinders?
15:57:07 <bswartz> or am I missing something
15:57:20 <zhongjun> so, different people make different software :D
15:57:26 <vponomaryov> bswartz; why not make good example for Cinder? )
15:57:34 <gouthamr> however, can we have an extension on this pl0x?
15:57:53 <bswartz> gouthamr: you just said we'll get it in shape today?
15:58:12 <gouthamr> bswartz: sure, but i can't expect reviewers to take a look at it as we shape it
15:58:19 <bswartz> okay
15:58:27 <tommylikehu> +1 for another extension
15:58:28 <bswartz> what's the argument for doing anything at all?
15:58:28 <gouthamr> and i don't think zhongjun will stay up much longer
15:58:38 <bswartz> why not punt to queens
15:58:48 <zhongjun> I can :D
15:59:11 <bswartz> I guess if we punt to queens we can't set a good example for cinder
15:59:14 <gouthamr> this is a reasonable improvement, i think pike is enough time to get it right..
15:59:26 <bswartz> because cinder will probably do whatever they're planning to during pike
15:59:55 <bswartz> okay we're out of time, let's make this last decision in the #manila channel
16:00:06 <bswartz> please go to the manila channel for 2 minutes
16:00:09 <bswartz> #endmeeting