15:02:27 #startmeeting manila 15:02:28 Meeting started Thu Jan 15 15:02: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:02:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:32 The meeting name has been set to 'manila' 15:02:41 oh well 15:02:47 hi 15:02:48 #topic dev status 15:02:52 Nice! 15:02:59 ok, here is dev status: 15:03:04 1) Share access levels 'ro' and 'rw' 15:03:08 looks like we have recording but not channel topic management 15:03:09 BP: #link https://blueprints.launchpad.net/manila/+spec/level-of-access-for-shares 15:03:19 gerrit: 15:03:19 - client #link https://review.openstack.org/144298 15:03:19 - server #link https://review.openstack.org/144617 15:03:22 status: finished, ready for review 15:03:29 2) Manage/unmanage shares 15:03:33 BP: #link https://blueprints.launchpad.net/manila/+spec/manage-shares 15:03:37 gerrit: #link https://review.openstack.org/147495 15:03:40 status: work in progress 15:03:45 3) Functional tests for manilaclient 15:03:48 BP: #link https://blueprints.launchpad.net/python-manilaclient/+spec/functional-tests 15:03:53 status: CLI tests from Manila project and its tempest plugin were ported to manilaclient and new were added. Right now it is read-only tests. 15:04:00 gerrit: 15:04:01 - docs update #link https://review.openstack.org/147161 15:04:01 - tests themselves #link https://review.openstack.org/137393 15:04:07 4) Single_svm mode for Generic driver 15:04:11 BP: #link https://blueprints.launchpad.net/manila/+spec/single-svm-mode-for-generic-driver 15:04:15 gerrit: #link https://review.openstack.org/142403 15:04:18 status: ready for review 15:04:25 That's the main 15:04:43 okay 15:04:49 I'll review 1 and 4 soon 15:04:53 2 is on the agenda for today 15:05:10 any question before we move on? 15:05:24 #topic Rename driver_mode decision 15:05:42 okay last week blew by fast and I didn't answer the questions raised on the ML 15:05:44 so I'll do so now 15:06:19 is chen here? 15:06:33 bswartz, yes 15:06:36 ok 15:07:01 so there can be relationship between share servers and virtual machines 15:07:08 however that's up to the driver 15:07:22 many drivers do in fact create a VM per share server 15:07:43 the point of the share_server construct was to enable that model, but not to force it 15:08:12 regarding why the scheduler needs to know about share servers 15:08:27 typically a share_server is a relatively expensive object to create (inside the driver) 15:09:10 it's usually preferrable for the scheduler to send requests to create a 2nd, 3rd, etc share to the same backend where the 1st share was created for any given tenant 15:09:30 at least, we want to allow the administrator to make that decision if he/she chooses 15:09:41 so the scheduler needs to know what's already been created and where 15:10:04 bswartz, what you mean " enable that model, " ? and "expensive object" 15:10:51 we wanted to create a persistence model in manila so that driver that did create VMs would have a place to track them 15:11:57 and VMs are typically an order of magnitude more resource intensive than individual shares 15:12:02 make sense? 15:12:08 bswartz, yes 15:12:49 okay 15:13:08 bswartz, we want VMs be tracked => in share server. But share server is not limited by VMs. It can contain other infomations too ==> up to driver ? 15:13:22 yes 15:13:46 and if someone comes up with a case where the info we store for the share server isn't enough, we can consider changing the model to add more info 15:13:58 the share_server model works well for existing drivers 15:14:08 if a new driver doesn't fit the model, we can talk about how to change it 15:14:20 the goal is to give driver authors flexibility 15:14:28 cool 15:14:31 but I get that too much flexibility creates confusion 15:14:56 so I saw the proposal for the concept of a "dummy share server" 15:15:32 I'm not sure that would offer any advantage over letting manila know explicitly that driver will never create share servers 15:15:56 and if manila knows that fact, then instantiating a dummy object doesn't server any purpose that I can think of 15:16:11 so share server mode indicates there is startup cost? 15:16:33 that depends on the backend 15:16:37 isn't it also about using the network setting passed in? 15:16:57 I mean, we know that the generic driver has to create a nova VM for each tenant/share network and creating nova VMs is not instantaneous 15:17:36 so after the first share is created, it's strongly preferable to create additional shares on the same VM if possible 15:17:49 scheduler will assume startup-cost and do share-server-affinity for additional share -- but that could be tuned later 15:18:21 yeah basically 15:18:36 bswartz, "preferable to create additional shares on the same VM if possible" ==> is there a chance admin would like create more share-server for higher throughput ? 15:18:43 we will make the information available, and the administrators should be able to tune the scheduler how they choose 15:19:24 chen: the driver is ALWAYS able to create new storage_servers if it's in the multi_svm mode 15:19:25 chen: right now if you want separate share server, just use another one share-network 15:19:33 that's a driver decision 15:19:42 s/storage_server/share_server/ 15:20:19 if the admin creates several share networks related to the same private network (I do not know why he would do that), then a new share server would be created while it is not necessary 15:20:21 the point of making the scheduler aware is to steer requests to the same backend 15:20:53 a multi_svm backend manages a large pool of resources typically 15:21:04 ganso_: correct 15:21:15 although share_networks are created by tenants not admins 15:21:46 yes, sorry, replace that word by tenant in that case 15:22:00 still, isn't this a problem in the scenario we are discussing? 15:22:17 it is resources being wasted 15:22:39 ganso_: that's why we have a quota on share_networks 15:23:12 the admin may choose to bill based on share_networks or limit them to 1 or 2 per tenant 15:23:50 bswartz: but then that quota may conflict with the scenario that he may have several private networks and would not be creating several share_networks per private networks. Shouldn't the option to do this be blocked or something? 15:24:17 ganso_ that would be between the tenant and the admin to work out 15:24:26 we're just providing the tools 15:25:23 If you can thinking of a way to exploit the current design with a DOS attack, please file a bug and we'll fix it 15:25:25 back when I was coding that part in my driver, I was torn between just throwing an error because it would simplify things, or support that scenario that has no use cases that I know of 15:25:53 if you can think of a more user friendly way to prevent bad users from doing things, let's talk about it 15:26:10 yea, I need to think about it 15:26:12 ganso_: ah I get it 15:26:26 I do not know the solution to this "problem" 15:27:04 yeah the intention is that if there are multiple share networks, that new share_servers will get created if it's a multi_svm backend 15:27:11 which brings me back to the current topic 15:27:18 the driver mode name 15:27:35 #link https://etherpad.openstack.org/p/manila-driver-modes-discussion 15:28:54 or not name, but choose an approach to distinguish two driver modes. 15:28:54 I see support for the boolean option 15:29:12 and after writing that etherpad I myself was starting to lean towards the boolean option 15:30:06 has everyone seen the proposal from markstur? 15:30:44 bswartz, still has a question for markstur_ : If I create a share without "share-network", the I get a share, the Export location might be $gluterfs-ip:/manila-volume0/share-xxxx. 15:30:44 Is there a chance my instances can't reach $gluterfs-ip at all ? 15:30:44 Eg, $gluterfs-ip = 192.168.6.98, but the network mask can be 255.255.0.0 or 255.255.255.0. 15:30:45 I'm a openstack user. I'm not the admin. I don't know what $gluterfs-ip stands for. 15:31:23 chen: network infrastructure is below Manila 15:31:34 I believe we talked about the possibility for a driver to support "both" modes 15:31:35 and we concluded that it's better to simply run 2 backends if that's the behavior you want 15:32:24 the reason for that is that the "driver mode" is reported back to the scheduler and can be associated with share_types, etc 15:32:28 bswartz, nope. I jut wander when user would use the single_svm_mode => only when the user know the network => user == admin ? 15:32:37 chen: so, it is up to network infrastructure of cloud whether you instances are able to connect to VMs or not 15:32:43 it's important to keep the 2 driver types separated 15:33:07 chen: single_svm mode is all around simpler, but less secure 15:33:25 it's up to the administrator to decide what he wants to or is able to implement 15:34:06 and not to disparage single_svm mode -- it can still be made to be perfectly secure, it's just harder 15:34:49 bswartz, but how user know what admin did ? especially when manila has multi-backend 15:34:50 bswartz: need to wrap up this topic and start other 15:34:55 so I'd like to call for a vote on these options if all the questsions 15:35:05 I'm with manage_share_servers=true, should we just vote and end it? 15:35:40 Is one option to vote to not change yet? 15:36:02 you mean to vote to discuss for another week? 15:36:06 I suppose that's an option 15:36:24 ugh, yes. Don't like the current names, but the new ones seem to need some thinking. ugh again 15:36:34 okay we'll see how this goes 15:36:50 anyone if favor of keeping the current names? 15:37:21 wait I have a better idea than doing this in IRC 15:37:31 please put your votes in the etherpad 15:37:32 online poll? 15:37:34 oh 15:37:39 by adding a +1 (name) to the option you like 15:38:00 https://etherpad.openstack.org/p/manila-driver-modes-discussion 15:38:12 ok 15:38:36 bswartz: are you picking the boolean name? 15:38:46 bswartz: the boolean option has lots of names 15:38:49 bswartz: oh, I see, it is below 15:39:29 who put the -1 on the boolean option? 15:39:58 vponomaryov: is that your -1? 15:40:06 I think that's valeriy -1 that name, but still supports boolean 15:40:11 bswartz: it is for one of names 15:40:18 ther is another +1 for another name 15:40:19 okay 15:40:32 so there is unanimous support for a boolean option 15:40:37 the question is which one 15:40:41 so who flips the coin? :) 15:40:54 did those that put +1 under "driver_handles_share_servers" prefer that option name? 15:41:15 what about multi_share_servers, use_share_servers, or manage_share_servers ? 15:41:26 wait 15:41:27 5x3 15:41:40 6x3 15:41:54 I didn't have a preference 15:42:21 but it sounds like y'all do 15:42:26 i'd go either way, but vp's -1 convinced me 15:42:34 #agreed driver_mode=single/multi_svm will be replaced by driver_handles_share_servers=True/False 15:43:06 okay moving on 15:43:21 #topic Use bashate for bash script checks 15:43:23 manage_share_servers will conflict with importing share servers if we implement it 15:43:32 toabctl: you're up 15:43:45 solved now 15:44:04 u_glide, good point 15:44:08 nothing to discuss? 15:44:12 ah. it's basically about adding a check for shell scripts. 15:44:37 I read the commit message and reviews 15:44:43 vponomaryov asked me to add this topic to the agenda. 15:44:52 is this really important? 15:45:00 how many bash scripts do we even have? 15:45:05 from my side there's nothing to discuss. I would just accept the commit. vponomaryov ? 15:45:15 I have a question 15:45:17 about my bugs 15:45:38 toabctl: its not clear what possibilities does it have 15:45:43 https://bugs.launchpad.net/manila/+bug/1410221 and https://bugs.launchpad.net/manila/+bug/1410246 15:45:46 ganso_: please save them for the end if we have time 15:45:52 toabctl: what exactly can do 15:45:53 ganso_: otherwise #openstack-manila 15:45:53 ok, sorry, I thought we were open 15:46:13 vponomaryov: see README here: https://github.com/openstack-dev/bashate 15:46:26 toabctl: which bash scripts were you thinking needed these checks? 15:46:29 ganso_: i think we are still on the topic of bashate 15:46:42 bswartz: all scripts we have in our codebase 15:46:43 lpabon: yes, looks like so, sorry 15:46:55 ganso_: no problem :-D 15:47:07 maybe I'm dense, but I didn't think we had that many 15:47:23 I'm looking now 15:47:48 I guess we can save this discussion for the code review 15:48:08 my gut feeling is that it's not a bad thing, but it also doesn't add much since bash is not a big part of manila 15:48:11 bswartz: bashate is also used by devstack. so if we want to get our contrib/devstack stuff merged at some point we need to pass the tests anyway. 15:48:22 so it might be a waste of resources to run it 15:48:41 anyways everyone can weigh in on the code review 15:48:47 toabctl: it can be fixed in commit with devstack 15:48:53 let's move on 15:48:53 denseif something appear 15:49:03 #topic Share manage/unmanage 15:49:08 sure. as I don't have a stron opinion about it. reject or accept it. 15:49:18 +1 for move on 15:49:49 so a few of us have been spending time thinking about how to add a manage/unmanage feature to manila comparable to what cinder has 15:50:22 for the driver_handles_share_servers=False drivers, I think it's pretty straighforward 15:51:03 those driver will have to add methods to either allow or veto a share manage operation 15:51:23 drivers will be free to veto a share manage operation for any reason 15:52:05 share manage is an admin-only action and the admin does it with knowledge of where the existing data actually is, so if a manage operation fails, the admin can typically make a change and retry until it succeeds 15:52:54 unmanage is the reverse -- taking a share created by manila and removing it from the manila DB but leaving the data intact wherever it exists 15:53:15 the problem is that this get far more complicated with driver_handles_share_servers=True drivers 15:54:08 because there is a question of how manila can take over ownership of SVMs created outside manila, and what happens to any existing data on those SVMs after they're taken over 15:54:44 right now we're leaning toward a share-server-manage/unmanage feature as well 15:55:45 could share-server-manage be split to a separate later thing? Is it needed for share-manage/ 15:56:10 bswartz: can you give a pointer to a description of the Cinder feature? 15:56:17 one thing we're struggling with is whether manila completely owns the share-server after it's managed, or not 15:56:39 markstur_ Yes, we could 15:56:50 I suppose some shares/drivers would have to bring in a share-server with the share(?) 15:56:59 markstur_: it's needed to manage existing shares if you have a driver_handles_share_servers=True backend 15:57:14 we could decide to not support that case at all and only allow managing of shares if driver_handles_share_servers=False 15:57:37 +1 15:57:37 because it will simplify first implementation of this feature. And we can return to this question later, when more users give feedback about their needs. 15:57:58 bswartz: manila probably doesn't have control on whether the share-server is also used outside of manila or not 15:58:10 personally I would like to support both cases, but I agree that it's possible to start with something simple and add to it 15:58:30 xyang_: having share-server entity we assume owning by manila 15:58:33 xyang1_: it can't prevent that, but we can decide if we want to support it or not 15:58:51 if we don't support it, then all bets are off if you do something you're not supposed to 15:58:51 ok 15:59:06 if we do support it, then we have to think about what problems that could cause down the road 15:59:21 when share-manage provide [share-network] then a share server can be created or found 15:59:39 unfortunately we're out of time and we'll have to continue this topic later 15:59:45 markstur_: manage is "registering" something already existing 16:00:18 #endmeeting\