15:01:05 <bswartz> #startmeeting manila 15:01:06 <openstack> Meeting started Thu Oct 3 15:01:05 2013 UTC and is due to finish in 60 minutes. The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:10 <openstack> The meeting name has been set to 'manila' 15:01:24 <bswartz> hello! 15:01:28 <vbelokon> hi! 15:01:28 <shamail> Hello everyone. 15:01:28 <caitlin56> Morning 15:01:31 <rushiagr2> hi all! 15:01:32 <yportnova> hi 15:01:34 <vponomaryov> hi 15:01:51 <bswartz> sorry I didn't put an agenda up on the wiki this week 15:01:56 <bswartz> we'll have to make it up as we go 15:02:35 <bswartz> My ideas for the networking stuff are starting to get clearer, but I still don't have a API design 15:03:01 <bswartz> I think I have enough information that I can update the wiki with some details though 15:03:19 <bswartz> first let's talk about the last week though 15:03:21 <glenng> ls -l 15:03:40 <bswartz> glenng: welcome! 15:03:59 <glenng> Thanks. Sorry for typing int he wrong window :-) 15:04:28 <bswartz> glenng is new to the team here at netapp 15:04:31 <rushiagr2> I did some preliminary testing with manila, using CLI, and filed some bugs 15:04:56 <bswartz> do we have anyone else new we need to introduce? 15:04:57 <rushiagr2> minor issues mostly 15:05:11 <bswartz> rushiagr2: thanks 15:05:27 <bswartz> rushiagr2: anything you'd like to discuss? 15:05:44 <caitlin56> Eventually we want to deal with virtual servers, but the network model itself would have to proceed that. 15:06:34 <rushiagr2> bswartz: not much.. I'd like to help with anything non-network related. I hate networking stuff :) 15:06:42 <bswartz> rushiagr2: lol 15:07:47 <yportnova> bswartz: I have done some minor bug fixes 15:08:09 <bswartz> yportnova, vbelokon: anything you want to share? 15:08:16 <yportnova> Started working on docs https://wiki.openstack.org/wiki/Manila/docs 15:08:18 <shamail> Are we on the networking topic or are we discussing last week at the moment? 15:08:32 <shamail> Sorry, my chat was lagging. 15:08:33 <bswartz> #topic status 15:08:40 <bswartz> shamail: still status 15:08:54 <bswartz> the networking will be next 15:09:22 <yportnova> Also we filed 3 blueprints - two connected with Oslo and one - using taskflow 15:09:47 <bswartz> thanks -- I haven't yet looked into taskflow 15:09:57 <bswartz> I understand it will probably be important 15:09:59 * rushiagr2 is excited to see taskflow into manila 15:10:33 <bswartz> can I ask if anyone is working on new backends yet? 15:10:38 <rushiagr2> I saw there have been some issues with taskflow in cinder 15:10:54 <rushiagr2> looked like it was hastily merged -- not good test coverage and some high-critical bugs introduced 15:10:55 <bswartz> I'm eager to see some contributions to help us make our case for incubation 15:11:17 <caitlin56> I almost have a commitment to doing a backend for Nexenta. We'll probably have people working on it in 2 weeks. 15:11:17 <shamail> bswartz: We plan to start working on back end. 15:11:17 <bswartz> rushiagr2: I thought that taskflow was delayed to icehouse for cinder 15:11:56 <rushiagr2> bswartz: ah! I thought it was merged already.. Definitely I must be wrong.. not attending Cinder meetings lately 15:11:59 <shamail> bswartz: I'll connect with you offline (in the other room) to understand how to begin that process. 15:12:04 <bswartz> caitlin56, shamail: thats good news, but I'm hoping for some early contributions 15:12:26 <caitlin56> I'll be proposing a new cinder backup via taskflow for icehouse. It should be a prototype for efficient use of backends. 15:12:28 <bswartz> anything that will help demonstrate multivendor participation in the project to the openstack gonvernance bodies 15:12:36 <caitlin56> Which makes it very relevant for Manila. 15:12:38 <shamail> +1 15:13:01 <bswartz> shamail: okay 15:13:33 <bswartz> caitlin56: that sounds interesting, I look forward to it 15:14:00 <bswartz> okay so let's move on then 15:14:06 <bswartz> #topic networking 15:14:23 <bswartz> I still don't have my new thoughts written down on this topic, so I'll try to express them here 15:14:55 <bswartz> It's pretty clear that priority #1 will be to support full 2-way network connectivity between tenants and backends using neutron 15:15:24 <bswartz> I don't want to rule out the other approachs -- and I still think a plugin model may be appropriate, but that particular use case seems to be the dominant one 15:16:38 <bswartz> So that means that backends will need to be able to "join" a tenant's network, presumably by creating new network virtual interfaces on the storage controller dynamically, or something equivalent to that 15:17:07 <bswartz> also, it's important that storage controllers can isolate tenant data so tenant A can't see tenant B's data, and vice versa 15:17:12 <caitlin56> bswartz: *and* associate it with a file sharing context. 15:18:04 <bswartz> In order to join the tenant network, we'll need to integrate with neutron to obtain some IP addresses, etc 15:18:54 <bswartz> And because security will be important in at least some cases, there need to be an interface for tenants to supply security information to manila, such as: 15:19:24 <bswartz> DNS server IP, LDAP server hostname, Kerberos server hostname, Kerberos account credentials 15:20:06 <bswartz> These details could be supplied either with each request to provision storage, or we could add a separate API to allow the user to provide them up front and then reference them later 15:20:20 <caitlin56> If they can attach to a tenant network the virtual servers should be able to find the other servers the same way they would have in an in-house network. 15:20:24 <bswartz> I'm undecided on which approach is better 15:21:14 <bswartz> I'm leaning towards making it a new API, so that the share-create API doesn't get bogged down with a bunch of extra parameters 15:21:23 <shamail> I think separate API might be useful 15:21:29 <bswartz> also, different storage protocols will have different information for security 15:21:43 <bswartz> a CIFS share will care about the AD domain, and not about Kerberos 15:22:20 <bswartz> anyone here from RedHat who can talk about what security details Gluster would need? 15:22:23 <shamail> bswartz: We may also have shared file-systems that span tenants, right? We would want these file-systems to get different config information than the individual tenant 15:22:29 <caitlin56> But wouldn't a file server already know whether to look for AD or LDAP? 15:22:54 <bswartz> shamail: I think that use case would be rare, I'm not even convinced we need to support it at all 15:23:14 <shamail> bswartz: okay, I agree. I was thinking binaries. 15:23:16 <eharney> bswartz: not off the top of my head, but i can think about it and get back to you 15:23:38 <caitlin56> shamail: single tenant has to control any given file system. That's simple. Why not just leave it at that. 15:23:38 <bswartz> caitlin56: I think you'd need to tell it 15:24:00 <bswartz> caitlin56: a tenant might have multiple AD domains, for example 15:24:12 <caitlin56> bswartz: but aren't there already mechanisms for tenants todo that. 15:24:18 <bswartz> caitlin56: a request for storage needs to be associated with exactly 1 domain 15:24:34 <bswartz> caitlin56: if there are I need to learn about them 15:25:12 <bswartz> shamail: I can imagine a case where 2 tenants could share a filesystem -- but that would only work when the 2 tenants shared a lot of other infrastructure 15:25:28 <caitlin56> bswartz: my concern is that I would prefer if my VServer did not have to be an OpenStack Vserver. 15:25:41 <bswartz> shamail: I think that's probably an edge case we can avoid dealing with in the first version 15:26:27 <bswartz> caitlin56: I don't get what you mean 15:26:39 <shamail> I agree with both of you (bswartz and caitlin56). I can write something up in the future but not a V1 requirement. 15:26:57 <caitlin56> I'd rather that the VServer logic didn't have to know much about openstack after it attached to the network. 15:28:15 <bswartz> caitlin56: the "vserver" doesn't need to know about openstack, but manila needs to know enough about the tenant that it can make the vserver work properly 15:28:57 <bswartz> I'm fairly certain that manila will need to make "vservers" explicitly join various tenant domains 15:29:02 <caitlin56> manila knowing is no problem. 15:29:19 <bswartz> and I'm using the term "vserver" here loosely -- it's a NetApp term but I hope the rest of you understand what it is 15:30:37 <bswartz> storage backends will need to present views of themselves which are compatible with virtual infrastructure 15:30:54 <vponomaryov> dont forget about policies for each API command, it is also usefull to restrict access 15:31:06 <bswartz> It's important that 10 or 100 tenants can all have their manila storage on the same physical backend server 15:31:35 <bswartz> Otherwise the approach won't scale 15:32:02 <caitlin56> It's also important that each tenant be able to manage ACLs internally the same way that they alrady manage them. 15:32:03 <bswartz> that necessarily means that backends will have multiple IP addresses and be in multiple domains though 15:32:18 <bswartz> I'm not sure how well other storage backends can cope with requirements like that 15:32:56 <shamail> bswartz: The principle requirement is to provide adherence with tenant security and connectivity requirements. The actual aspect of how a vendor supports multiple AD domains, LDAP, network address spaces should be considered by each vendor given their architecture. 15:33:08 <bswartz> shamail: yes 15:33:45 <shamail> vponomaryov: +1 15:34:19 <bswartz> I don't want to perscribe how backends should be designed, but there are certain features which will be necessary, and could be hard to implement w/ certain hardware/software 15:34:54 <bswartz> I want the backend interface to give vendors are much flexibility as possible while still providing the right kinds of security guarantees to the ultimate users 15:35:19 <bswartz> there's a built in tension there 15:35:50 <caitlin56> bswartz: if someone has a computer room network right now, and a system for setitng ACLs and users in their LDAP/AD server, they should be ale to port that entire environment for managing permissions within their domain. 15:36:22 <bswartz> yes, but with one exception 15:36:47 <bswartz> whatever they're using to manage the ACLs on their storage backend, will have to switch to calling manila APIs to manage the security of the storage provided by manila 15:37:13 <bswartz> because manila will hide the details of the backend storage implementation from the tenant, exactly like cinder does 15:38:47 <bswartz> okay so I plan to update the wiki with some of the stuff we discussed today 15:38:57 <bswartz> and to outline changes to the API to enable this stuff 15:39:13 <bswartz> in parallel we need to see how we can actually implement these APIs in the generic LVM backend 15:39:35 <bswartz> yportnova, vbelokon: I'm going to need your help with that part 15:39:48 <yportnova> bswartz: sure 15:40:13 <bswartz> #topic open discussion 15:40:25 <bswartz> okay so that's about as much as I have for networking 15:40:39 * rushiagr2 comes out of hibernation 15:40:39 <bswartz> anyone have anything else for today? 15:40:55 <rushiagr2> whats the plan of incubation request? 15:41:00 <shamail> I'm going to drop. Have a great day/night everyone! 15:41:06 <bswartz> shamail: thx 15:41:57 <rushiagr2> i mean, any date we are looking at? 15:42:51 <bswartz> well if ther are no contributions of working backends planned for the next few weeks we may need to submit an incubation request based on the work that's been done so far by NetApp+Mirantis, and rely on the fact that we haev significant community particitions in these meetings to convince the OpenStack board to accept us for incubation 15:43:14 <bswartz> by 2 weeks from today I'd like to have the request submitted 15:43:34 <bswartz> I guess I'll poll people individually about whether we're likely to see any code before then 15:43:56 <bswartz> if not, we may not wait and just take our chances 15:44:09 <bswartz> does anyone know who ultimately decides the fate of incubation requests? 15:44:21 <bswartz> is it the TC or the board of directors or another group? 15:44:35 <rushiagr2> the HP and IBM folks were also interested in it isnt it? Havent seen them around from a while.. 15:44:52 <rushiagr2> I think it happens in the weekly TC meeting 15:45:56 <bswartz> we've had interest from the following companies: RedHat, IBM, EMC, Nexenta, HP, Intel 15:46:07 <bill_az> rushiagr2: IBM here, we will be submitting BP for GPFS backend 15:46:09 <bswartz> maybe a bit from solidfire 15:46:33 <bswartz> Intel probably won't contribute but the rest of those companies are all considering backends 15:46:35 <bill_az> rushiagr2: and most likely at least one other - not sure of timing yet 15:46:46 <vbelokon> Incubation process - https://wiki.openstack.org/wiki/Governance/Approved/Incubation 15:47:05 <bswartz> bill_az: can we expect anything in the next 2 weeks or are you looking at a longer timeline? 15:47:29 <bill_az> bswartz: will try for next two weeks, but can't commit on that 15:47:37 <rushiagr2> bill_az: sorry. Didnt know you are from IBM 15:47:53 <bill_az> no worries! :-) 15:48:12 <esker> It is the TC 15:48:17 <bswartz> okay well I'll ask around a bit more but it seems that our best course of action may be to make the incubation request now 15:48:41 <esker> The TC will want to see evidence of diverse community participation 15:49:13 <bswartz> esker: we have ample evidence of participation in these meetings, but it looks doubtful we'll have evidence in gerrit before the HK conference 15:49:15 <esker> So the IBM BP as well as the RH ones will need to be emphasized in the incubation request 15:49:40 <esker> BP in lieu of submissions... indicates intent 15:49:48 <bswartz> rushiagr2: thanks for your particiation finding and filing bugs 15:50:03 <esker> rushiagr2: distinguished alumni ;-) 15:50:12 <rushiagr2> :-P 15:50:56 <bswartz> #action bswartz submit incubation request by end of next week 15:51:02 <bswartz> okay I don't have anything else 15:51:39 <bswartz> okay everyone thanks for attending 15:51:55 <bswartz> see you next week or in #mania 15:52:02 <bswartz> #manila 15:52:13 <bswartz> I keep making that typo -- hope it doesn't mean I'm going insane 15:52:25 <bswartz> #endmeeting