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