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