15:00:02 <bswartz> #startmeeting manila
15:00:02 <openstack> Meeting started Thu Aug 20 15:00:02 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:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:05 <openstack> The meeting name has been set to 'manila'
15:00:09 <bswartz> hello all
15:00:09 <cknight> Hi
15:00:13 <csaba> hi
15:00:13 <toabctl> hi
15:00:13 <ganso_> hello
15:00:14 <abalutoiu> hi
15:00:17 <lpabon> o/
15:00:26 <xyang1> Hi
15:00:33 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:00:36 <rraja> hi
15:01:07 <zhongjun2> hi
15:01:18 <bswartz> markstur zhongjun2: courtesy ping
15:01:37 <dustins> o/
15:02:05 <u_glide> hi
15:02:12 <bswartz> hmm first topic is markstur's
15:02:12 <toabctl> bswartz: I just have 1/2 hour if there's something to discuss about install guide docs
15:02:14 <markstur> hi
15:02:19 <bswartz> there he is!
15:02:24 <bswartz> #topic Common Capabilities
15:02:44 <markstur> I think we can wrap up thin and dedupe
15:02:55 <bswartz> #link https://review.openstack.org/#/c/209781/
15:03:07 <markstur> There have been minor issues with the example, but
15:03:26 <markstur> I think the agreement is there.  Zhongjun had an issue, but his patch landed so I think he's probably happy
15:03:49 <markstur> Any remaining issues on the way thin is handled?
15:04:01 <markstur> Also I wanted to mention snapshot_support
15:04:13 <markstur> Valeriy has a patch for that
15:04:26 <markstur> It is fully implemented in client, etc.  Like DHSS, but optional
15:04:44 <bswartz> I think zhongjun2 still had remaining concerns
15:04:57 <markstur> The think I wanted to point out is that this will be set to True or False in every share type
15:05:05 <bswartz> zhongjun2: did you want to raise any issues now?
15:05:48 <markstur> So I don't think there is a way to have a share-type that doens't care about snapshot_support (and dhss)
15:05:51 <zhongjun2> yes
15:06:07 <markstur> zhongjun2, go ahead
15:06:20 <zhongjun2> I send a email to you.
15:06:20 <bswartz> markstur: correct, you have to have snapshot_support=True or False
15:06:46 <zhongjun2> about wheather Replace thin/thick capabilities with thin_provisioning.
15:07:03 <bswartz> zhongjun2: yes there are 2 issues here
15:07:50 <bswartz> We already decided that, for UI simplicity, we should have thin_provisioning=True/False ONLY and no capabilities about thick
15:08:16 <bswartz> backends that do thick provisioning communicate this by advertising thin_provisioning=False
15:08:37 <bswartz> the side effect of this decision is that backend now cannot have pools that support both
15:08:49 <bswartz> I see this as a feature not a bug
15:08:49 <markstur> I think the issue is that the pool name now needs to be tricked to make one backend pool look like 2 manila pools (thin/thick)
15:09:06 <markstur> zhongjun2, is suggesting that that is confusing to users
15:09:37 <bswartz> based on the work that xyang1 did in Cinder, I concluded that mixing thin and thick provisioned shares/volumes in the same pool will usually lead to serious problems
15:09:40 <markstur> I understand the inconvenience, but we can't expect always a 1-to-1 mapping of manila pool with array pool
15:10:01 <markstur> bswartz, worth mentioning that we'll be inconsistent with Cinder
15:10:02 <zhongjun2> If I add identifying prefix or something behind pool name, May be the user feel very confused, and can not find a match pool name on array.
15:10:47 <zhongjun2> inconsistent with Cinder? means thin and thick both supported?
15:10:51 <bswartz> zhongjun2: it sounds like you're taking the same pool on your backend and reporting it to manila twice, once with thin_provisioning=True and once with thin_provisioning=False
15:11:12 <zhongjun2> yes
15:11:15 <xyang1> We need to come up with some examples on how the driver can implement this though, as I pointed out in Mark's patch
15:11:29 <bswartz> zhongjun2: that will create problems for the manila scheduler because share creation will actually decrease free space in both pools but manila will only know about one pool
15:12:31 <bswartz> My recommendation is to allow the admin to statically configure each pool as thick or thin (or the whole backend) using the driver's config
15:13:09 <bswartz> here is the problem with mixing thick and thin in the same pool (hopefully I can do this quickly)
15:13:33 <xyang1> How to set up pools in conf and have driver parse it and determine which can be used as thin or thick, etc
15:13:53 <bswartz> if you have a mixed pool, and you start by creating a few thin provisioned volumes, you will get an overcommit ratio of X
15:14:08 <bswartz> where X < 1
15:14:49 <bswartz> if you then create some thick provisioned volumes/shares in the same pool, your overcommit ratio can go way above 1, but the manila scheduler doesn't look at overcommit when scheduling thick volumes/shares
15:15:20 <bswartz> you can end up in situation where you overcommit significantly more than you intended to
15:15:39 <bswartz> if you have separate pools for thick and thin then the scheduler can regular the overcommit ratio correctly
15:16:03 <bswartz> does that make sense?
15:16:47 <markstur> Mixing them in one pool with the current scheduler would like fill fast and even out-of-space with thick shares
15:17:11 <markstur> s/like/likely/  or I should've said "possibly"
15:18:12 <markstur> Comments on thin before I paste in some comments on snapshot_support?
15:18:17 <bswartz> we of course can't prevent drivers from reporting the same pool twice but I'll warn you know that it will cause bad user experience because the scheduler will do the wrong thing
15:18:30 <zhongjun2> Whether to use depends on the users choice
15:18:34 <markstur> yes the naming needs to be tweaked
15:18:41 <markstur> the end-user won't see the name
15:18:52 <markstur> the admin should be able to figure out your naming methods from docs
15:18:57 <zhongjun2> Maybe is not out-of-space with thick shares
15:19:06 <xyang1> The max over sub ratio is determined by the admin based on space usage patterns.  No matter how you implement this, admin always have to check the real space comsumption and add storage if needed
15:19:48 <xyang1> That is why we need notifications on space usage
15:20:01 <bswartz> zhongjun2: if you're not convinced by my argument I suggest you start a mail thread about this topic on the manila ML and we can go into more detail
15:20:08 <bswartz> I want to let markstur finish with his topic
15:20:15 <markstur> So, on snapshot_suport since it is a significant thing it is forced to be set.
15:20:20 <markstur> But if we had a 3rd thing like this dhss/snap/3rd-thing then there would be 8 combos.
15:20:20 <markstur> We can't keep doing that.
15:20:24 <markstur> It could get difficult in a mixed environment to get the combos correct. Normally you have a "don't care" option.
15:20:30 <markstur> So I'm OK with doing this on snapshots, but I wanted to point out that we shouldn't normally do this.
15:20:34 <markstur> Yeah. I type fast.
15:20:40 <bswartz> markstur: lol
15:21:00 <bswartz> markstur: the motivation for making some extra specs user-visible is because they affect the API
15:21:03 <zhongjun2> ok, thanks
15:21:12 <bswartz> I don't actually expect real deployments to have all combinations
15:21:31 <markstur> Yes. But to be clear. Non-default impls will require a matching share type
15:21:39 <markstur> As long as people are aware of that.
15:21:58 <markstur> and we wouldn't do this if it wasn't a major driver splitting thing
15:21:59 <markstur> OK?
15:22:12 <bswartz> oh, you're concerned about the case where the default share type and the driver cause scheduling to fail out-of-the-box?
15:22:34 <markstur> Well you can't get there with default share types
15:22:39 <markstur> You need to know
15:22:56 <markstur> So non-snap drivers need to make that clear in their docs
15:22:58 <bswartz> the admin needs to make sure that all share types actually work, including the default
15:23:28 <markstur> I'm more worried about what it would look like if we did this again with a 3rd option.
15:23:33 <bswartz> the admin is supposed to know what his driver can support (by reading the docs) and configure share types appropriately
15:23:42 <bswartz> markstur: there's a 3rd option coming already
15:23:49 <bswartz> replication
15:23:55 <markstur> Normally extra-specs can be optional so there's a 'don't care" option
15:24:06 <bswartz> it will default to None, but there will be 3 other valid options
15:24:10 <markstur> Which is easy, but has a do-you-feel-lucky element
15:24:46 <ganso_> markstur: lol
15:24:47 <bswartz> markstur: the difference is that with most extra_specs, whether you get true or false, the end user can't perceive the difference through the cinder API
15:24:48 <zhongjun2> I will think again
15:25:01 <markstur> bswartz, yep
15:25:17 <markstur> So snapshot case makes sense. It is an important split like dhss
15:25:18 <bswartz> we're making decisions to add features that change the API -- and the user needs to know what they can and can't do
15:25:54 <markstur> OK.  I'm not trying to argue against it.  Just trying to make sure all are aware of it.  And also that we wouldn't do it for everything.
15:26:00 <zhongjun2> I fear that this combination will have more follow-up, aren't we all want to separate?
15:26:01 <bswartz> oh okay
15:26:21 <bswartz> those are both good points
15:26:54 <bswartz> user-visible extra specs are only added when we have no choice, because the feature has API impact
15:27:16 <bswartz> and admins need to be keenly aware of these extra_specs
15:27:25 <xyang1> markstur: Are you going to change manila ui for snapshots? The snapshots tab should not be there by default any more
15:27:25 <bswartz> okay next topic
15:27:40 <bswartz> xyang1: I think there's a patch already that does that
15:27:48 <xyang1> Ok
15:27:55 <markstur> Valeriy is on it
15:27:58 <bswartz> #link https://review.openstack.org/#/c/213242/
15:28:31 <bswartz> #topic Feature Freeze
15:28:50 <bswartz> so today is the last day to submit new feature patches for Liberty
15:29:23 <bswartz> most everything is ready for review right now, with the exception of 2 things from NetApp
15:29:52 <bswartz> those things should go up this afternoon
15:30:08 <bswartz> it's a good thing we didn't wait until the last minute....
15:30:16 <csaba> bswartz: RH has also some outstanding work
15:30:21 * bswartz chuckles
15:30:37 <bswartz> csaba: 23:59 UTC is the deadline to have it in gerrit with +1 from jenkins
15:30:38 <markstur> csaba, All your work is "outstanding"
15:30:45 <bswartz> markstur: +1
15:30:56 <bswartz> nice double entendre
15:31:15 <bswartz> the merge freeze is 2 weeks from today
15:31:41 <bswartz> for the next 2 weeks everyone should be focused on reviewing, rebasing, and merging features from this list:
15:31:49 <bswartz> #link https://launchpad.net/manila/+milestone/liberty-3
15:32:01 <csaba> markstur: thanks for the compilment
15:33:34 <bswartz> I'm working on an etherpad where we can get core members to sign up to review patches if we aren't getting enough core attention on stuff
15:33:52 <bswartz> currently it seems like we're getting pretty good review coverage though and that might not be needed
15:34:18 <markstur> bswartz, You have a -2 to prevent rebase nightmare with share instances. When is that going away?
15:34:35 <bswartz> next week if I see stuff that's not getting reviewed I'll start to look for core to assign to stuff
15:35:02 <bswartz> markstur: yeah share instances will cause rebase hell for many things and I didn't want to make that happen right before the deadline
15:35:27 <bswartz> I'll remove my -2 at 0:00 UTC tonight and workflow it again
15:36:13 <bswartz> anything not in gerrit by then won't be part of liberty anyways
15:36:56 <bswartz> and plenty of stuff will need rebasing, so submitters can start to work on that tomorrow in parallel with code reviews happening
15:37:46 <bswartz> csaba: I see 3 new bps -- I'll grab you after meeting today to discuss them
15:38:23 <bswartz> any questions about feature freeze / feature proposal freeze?
15:38:32 <csaba> bswartz: OK
15:39:12 <bswartz> #topic docs
15:39:40 <bswartz> toabctl: I know you had to leave but I think you know everything I'm about to say
15:40:10 <toabctl> bswartz: still looking but also in another phone meeting...
15:40:26 * annegentle waves
15:40:27 <bswartz> we are working on bringing manila's documentation up to part with the rest of the openstack project with the goal of having that done by Liberty release
15:40:32 <annegentle> I'm not totally caught up tho
15:41:02 <bswartz> I was surprised to find out that some documentation projects limit their content to defcore-only projects
15:41:17 <bswartz> the install guide is one of these, so toabctls manila install guide patch got -2'd
15:41:46 <bswartz> the good news is that the various guides in openstack-manuals have no such restriction, and that's where most of our focus will be during liberty
15:41:49 <annegentle> sorry bswartz I thought I was pretty clear on the diretion
15:41:58 <annegentle> direction, can't spell :)
15:42:20 <annegentle> bswartz: the vision is to have you all review your install directions in your repo
15:42:35 <bswartz> annegentle: that's what we can do in the short term
15:42:36 <annegentle> bswartz: and build to a common install guide, but we just don't have the infra structure right now
15:42:39 <annegentle> bswartz: yep
15:43:16 <bswartz> based on my private email thread with loquacities, I'm hopeful that there will soon be an "extended install guide" that we can be part of, along with several other non-defcore projects
15:43:32 <bswartz> perhaps not in liberty
15:44:31 <bswartz> anyways anyone who's working on docs should just be aware of what the docs team is up to and make sure they're aware of what you're up to so we don't get nasty surprises
15:44:47 <annegentle> I apologize for any surprises there, you all.
15:44:56 <xyang1> So we are free to add the user guide?
15:45:03 <bswartz> I'm learning as I go
15:45:22 <bswartz> xyang1: https://github.com/openstack/openstack-manuals/tree/master/doc/user-guide
15:45:27 <bswartz> https://github.com/openstack/openstack-manuals/tree/master/doc/user-guide-admin
15:45:43 <bswartz> these are both part of openstack-manuals and AFAIK they will take manila content
15:45:44 <annegentle> xyang1: I believe so but again the specialty team may have reasons so check in with them, https://wiki.openstack.org/wiki/User_Guides#Agenda_for_next_meeting is their weekly meeting
15:46:15 <xyang1> annegentle: Ok, i have submitted a patch
15:46:22 <annegentle> xyang1: ok, thanks
15:46:27 <annegentle> and thanks everyone for taking care of docs
15:46:31 <toabctl> and if unsure, ask on openstack-doc ML
15:46:43 <xyang1> annegentle: https://review.openstack.org/#/c/214758/
15:47:48 <bswartz> any other questions about docs?
15:48:17 <bswartz> we're still looking for volunteers for certain guides -- all of the core team members are working on at least 1 doc
15:48:48 <bswartz> ah here it is
15:48:52 <bswartz> #link https://etherpad.openstack.org/p/manila-liberty-documentation-sprint
15:49:45 <bswartz> #topic open discussion
15:49:49 <bswartz> anything else for today?
15:50:38 <bswartz> okay
15:50:46 <bswartz> I'll let you all go 10 minutes early
15:51:04 <bswartz> 8 hours until the FPF
15:51:15 <bswartz> use the time to get your patches up if you haven't already
15:51:27 <bswartz> #endmeeting