15:00:50 <bswartz> #startmeeting manila
15:00:51 <openstack> Meeting started Thu Oct 17 15:00:50 2013 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:54 <openstack> The meeting name has been set to 'manila'
15:01:03 <bswartz> hello!
15:01:04 <shamail> Hello everyone.
15:01:09 <vbellur> hello all
15:01:10 <caitlin56> hello
15:01:10 <rushiagr> o/
15:01:23 <yportnova_> hi
15:01:29 <bswartz> #link https://wiki.openstack.org/wiki/ManilaMeetings
15:01:39 <bswartz> for once I put an agenda together
15:01:54 <vponomaryov> hi
15:01:58 <rushiagr> bswartz: \o/
15:02:22 <bswartz> okay so I'll launch into my action item from last week
15:02:29 <bswartz> #topic Networking BP
15:02:33 * rushiagr started remembering about it only at the start of the meeting
15:02:44 <bswartz> #link https://blueprints.launchpad.net/manila/+spec/join-tenant-network
15:03:26 <bswartz> so this is the culmination of the thinking so far
15:03:51 <bswartz> once I thought through the details and wrote them down, it actually doesn't seem so bad
15:03:58 <vponomaryov> About this BP: Why do we need in manila api called "setup-network"?
15:03:59 <vponomaryov> In this case Manila will be mediator, one another failpoint.
15:04:22 <bswartz> vponomaryov: the API name may be poorly chosen
15:04:39 <bswartz> I strongly suggest that we change it, but I didn't have any better ideas when I was writing
15:04:59 <vponomaryov> question about mechanism, not name
15:05:24 <bswartz> well manila must be involved in the mechanism, since the backend drivers in manila will be doing most of the work
15:05:42 <bswartz> this is all about configuring the backends storage to join an existing tenant network
15:06:09 <bswartz> there will be some code shared between drivers -- most likely in the form of utility functions
15:06:34 <caitlin56> Question: in neutron terms, is this an additional tenant network, or just adding manila attributes to a tenant network?
15:06:40 <bswartz> all of the interactions w/ neutron are likely to be common, except that different backends will require fewer or more IP addresses
15:07:21 <vbellur> what would be the workflow here? create network -> create share & then attach share?
15:07:34 <bswartz> caitlin56: in neutron terms, we're connecting new resources into an existing network
15:08:00 <bswartz> those resources will be virtual with possibly a physical component as well (depending on the backend)
15:08:00 <shamail> Can you elaborate on "virtual NICs" concept inside Manila?  Is this referring to IP interfaces on the storage provider or is this layer residing in some external translation layer (L2/L3 mapping via neutron)?
15:08:45 <bswartz> shamail: this is referring to the IP interfaces on the storage
15:09:04 <shamail> bswartz: thanks.
15:09:07 <bswartz> shamail: In NetApp terms, it would be called a LIF (or a VIF on legacy systems)
15:09:14 <shamail> Yep. :)
15:09:29 <caitlin56> bswartz: and neutron probably thinks that the storage server has a virtual switch, right?
15:09:37 <bswartz> In Linux terms, it would be a tap interface
15:10:50 <bswartz> caitlin56: the storage server just needs a VLAN trunk -- or its equivalent in SDN terms
15:11:07 <shamail> The inclusion of 'trunking' threw me off, but that makes sense... Each LIF/TAP/etc would include a VLAN ID and the switch port is defined as a trunk passing all VLAN IDs.
15:11:17 <caitlin56> yes, and the other end of a vlan trunk is technically a switch.
15:11:45 <bswartz> correct -- but most storage servers don't use the term "switch" for their internal networking
15:12:24 <caitlin56> and to be real technical it is an IEEE 802.1 "Bridge", which everyone calls a switch.
15:12:43 <bswartz> caitlin56: showoff!
15:12:58 <shamail> Does this model still leave the door open on all three plumbing options (e.g. native  OVS support, VLAN support, and Gateway support)?  Initially it seems like it does, but does anyone have a different view?
15:13:31 <bswartz> shamail: I'm inclined to deprioritize the methods that aren't native
15:14:08 <caitlin56> I agree. for network plumbing stick with the stuff that Neutron supports.
15:14:09 <bswartz> i.e. anything that doesn't result in full 2-way network connectivity between the storage and the tenant network is likely to be limitted and less interesting
15:14:28 <caitlin56> The real question is are we also going to define a non-Neutron solution.
15:14:48 <shamail> bswartz: agreed
15:14:57 <bswartz> I'd like to leave the door open for gateway-based approaches in the future, but I think that it's better to get the main use case nailed rather than distract ourselves with lots of use cases
15:15:11 <caitlin56> +1
15:15:13 <rushiagr> bswartz: +1
15:15:14 <gregsfortytwo> I'm really new in here (just started reading docs two days ago), but I have to interject that any non-NFS/CIFS solution is probably going to have issues if every VM using it needs to have good native access :)
15:15:45 <KenD> are we planning on using the VLAN ID as a discriminator 'inside' the storage system?
15:15:48 <bswartz> gregsfortytwo: welcome!
15:15:58 <bswartz> gregsfortytwo: I'm not sure I understand your concern though
15:16:14 <KenD> "tenant-discriminator"
15:16:20 <caitlin56> gregsfortytwo: that is the advantage of the VLAN/VXLAN approach.
15:17:00 <bswartz> KenD: yeah the idea is that if tenant A is on VLAN 17 and tenant B is on VLAN 49, then the storage system needs to present network interfaces on each of those VLANs so that the tenants cannot access eachother's data
15:17:03 <caitlin56> VLANs are much easier to audit than NFS export controls.
15:17:19 <gregsfortytwo> well, I'm thinking about Ceph in particular since that's what I work on, but this would apply to Gluster or whatever as well — if the VM needs to have good support for the shared FS that will limit the OS you can use, or add a lot of necessary extra tooling to do stuff like install FUSE libraries
15:17:29 <bswartz> the concern goes deeper than auditting though
15:18:01 <caitlin56> And don't forget that we are proposing that each tenant be allowed to create multiple security domains.
15:18:02 <gregsfortytwo> in terms of networking in particular, if every VM needs to have direct IP address to all the storage nodes that's going to be a lot more work for Neutron
15:18:10 <bswartz> if a tenant has Active Directory setup for their CIFS, or if they have LDAP/Kerberos setup for their NFS, then the storage server needs to coordinate with the various domain controllers for security
15:18:46 <caitlin56> gregsfortytwo: if you are a multitenant environment, why wouldn't you already have tenant tagging?
15:19:07 <gregsfortytwo> but I don't want to drop in and derail my first meeting, just wanted to note it :)
15:19:32 <caitlin56> Just for reference, this is easy on the client side -- the real work is on the server side.
15:19:43 <bswartz> gregsfortytwo: I'm thinking that "More work" for neutron is just adding a few extra IPs -- once the backend is joined to the right VLAN its not any more work on an ongoing basis
15:19:51 <gregsfortytwo> k
15:20:32 <gregsfortytwo> like I said, just getting into all this
15:20:45 <bswartz> anyways, I appreciate feedback on the BP
15:20:50 <KenD> I am not sure that it would be any more work for neutron, there will already be tenant IDs set up
15:20:57 <bswartz> I expect we will continue discussing this design through the conference
15:21:28 <caitlin56> The only way this is more work for Neutron is if the tenants want multiple security domains specificaly for NAS.
15:21:44 <bswartz> gregsfortytwo: I'd like to know what specific requirements ceph might have because we intend to accomodate alternative protocols, and I just don't know enough of the details right now
15:21:50 <vbellur> would this mean that we modify the create_share API to pass the network identity?
15:21:51 <caitlin56> Which could happen, but neutron is there to serve tenants (just like Manila)
15:22:17 <gregsfortytwo> bswartz: would it be better to discuss over in #openstack-manila later today instead of right now?
15:22:29 <bswartz> vbellur: yes I mentioned that in the BP I think
15:22:53 <bswartz> gregsfortytwo: yes I'll grab you offline
15:22:56 <gregsfortytwo> cool
15:23:03 <vbellur> bswartz: ah ok
15:23:22 <bswartz> okay in the interest of time, next topic
15:23:29 <bswartz> #topic Other BPs
15:23:47 <bswartz> so I've seen a bunch of new BPs getting filed, and this is great!
15:24:15 <shamail> I had a question regarding Multi-backed support.  Did Manila keep the filter scheduler functionality that was introduced in Cinder?
15:24:22 <bswartz> I'm glad to see the interest in the project and I hope we can get several backends included by the end of Icehouse
15:24:22 <shamail> Doh, sorry. :)
15:24:46 <bswartz> shamail: yes we kept the scheduler
15:25:15 <caitlin56> It isn't the greatest method of aqdding servers, but we should follow what Cinder has.
15:25:21 <shamail> bswartz: Thanks, sorry for the deviation.
15:25:47 <bswartz> does anyone want to discuss a particular BP right now?
15:25:50 <bswartz> or is everything just a placeholder with details to come later?
15:25:51 * rushiagr makes a mental note to test manila filter scheduler in the coming week
15:26:10 <vbellur> bswartz: most BPs seem to be placeholders atm
15:26:37 <bswartz> caitlin56: I actually think that cinder's method of supporting multiple backends is superior to what neutron offers
15:26:46 <bswartz> caitlin56: do you have a better idea?
15:26:57 <shamail> We are still working internally on our design plan... But here is a place-holder BP for the driver.
15:27:16 <bswartz> note: I'm aware of some funkiness with how the scheduler actually works in practice, but those are implementation issues
15:27:27 <shamail> #link https://blueprints.launchpad.net/manila/+spec/emc-driver
15:27:32 <bswartz> the design of the scheduler is pretty solid IMO
15:27:45 <shamail> bswartz: +1
15:28:37 <bswartz> shamail: I updated your BP, targetted to icehouse
15:28:52 <bswartz> #topic Summit
15:28:54 <shamail> bswartz: thanks.
15:29:08 <bswartz> okay so the Hong Kong summit is just 2.5 weeks away (!!!)
15:29:29 <shamail> drinks on bswartz!
15:29:29 <shamail> :)
15:29:32 <bswartz> lol
15:29:35 <KenD> Do we have a finalized schedule for manila meetings? or an agenda?
15:29:47 <vbellur> shamail: +1
15:30:00 <bswartz> I want to have some meetings in Hong Kong for those who are able to travel
15:30:09 <KenD> shamail +1
15:30:12 <bswartz> my default plan is 1 or 2 unconference sessions
15:30:33 <bswartz> rigth now we're working on actually renting a room so we have guaranteed space
15:30:50 <caitlin56> bswartz: is it fair to say that the agenda for Hong Kong is focused on solidifying manila as a project, rather than on working on manila itself?
15:31:03 <bswartz> the main downside to unconference sessions is that they're limitted and we have to schedule them last minute
15:31:39 <bswartz> if we can get a room, I'll schedule something next week and announce it here in this meeting
15:31:51 <bswartz> otherwise we have to wait and see what we can get
15:32:01 <vbellur> ok
15:32:02 <KenD> should we formalize the session? or are we expecting low attendance in HK?
15:32:16 <bswartz> my goal will be to minimize overlap with cinder sessions, and to minimize overlap with neutron/nova sessions that might be of interest to this group
15:32:16 * caitlin56 will be there
15:32:21 <vbellur> maybe have a date so that we can plan our schedules around that?
15:32:37 <bswartz> KenD: we can't formalize it because we're not officially a project yet >_<
15:32:41 <shamail> bswartz: Appreciate that.
15:32:58 <caitlin56> +1 to waiting until after Cinder schedule is set to do Manila schedule.
15:33:19 <bswartz> regarding that, there were TC elections this week, so our request for incubation was not considered
15:33:37 <bswartz> I expect our request to be considered on tuesday, and I see no reason that it won't be granted
15:33:57 <bswartz> so hopefully we will be incubated the time of the conf
15:34:17 <shamail> bswartz: new here, does that mean that we won't get a chance for incubation or did the decision just get deferred a week or two?
15:34:19 <caitlin56> bswartz: when would it be considered? I'm trying to decide when to press the execs here to let me submit a blueprint for a Nexenta Manila driver.
15:34:24 <bswartz> regarding the agenda for our meetings, mostly I just want everyone to meet face to face since we'll likely be working together over the next 6 months
15:34:33 <shamail> bswartz: nevermind, you answered the question already.
15:35:08 <bswartz> I will prepare some background material we can present and discuss for anyone who hasn't been following us for the last month or 2
15:35:31 <bswartz> but I don't expect to do any serious arguing and decision making in HK, since we're still quite new
15:35:44 <glenng> bswartz: That will help.
15:36:14 <caitlin56> bswartz: I think that's the right set of objectives for now.
15:36:36 <vbellur> bswartz: sounds like a plan.
15:36:39 <bswartz> so next week I'll announce a meeting time/place if we're able to get a room
15:36:57 <shamail> bswartz: thanks.
15:37:01 <bswartz> otherwise we'll just use the whiteboards outside the unconference rooms
15:37:20 <bswartz> and I'll try to send out an email after I grab a slot
15:37:29 <bswartz> I have many of your email addresses already
15:37:40 <bswartz> i'll ping people who's addr I don't have
15:38:19 <bswartz> #topic open discussion
15:38:28 <bswartz> okay so are there any other topics?
15:38:32 <vbellur> any plans to improve our api documentation?
15:38:40 <bswartz> want to continue the discussion about the networking stuff?
15:39:02 <bswartz> vbellur: we plan to improve the docs, yes!
15:39:13 <bswartz> vbellur: unfortunately I don't have a timeline
15:39:23 <caitlin56> On doc, I'd suggest that we focus on *vendors* as much as users. Knowing how to plug in your NAS server is just as important as knowing how to use it.
15:39:37 <caitlin56> And probably more complex that how a user accesses it.
15:39:38 <bswartz> if anyone wants to help out there I'd appreciate it
15:39:55 <bswartz> yes writing docs that make it easy for vendors to write backends is important
15:40:02 <rushiagr> lets have it as a blueprint if it is not already there?
15:40:11 <vbellur> bswartz: yeah, maybe we should set a timeline for getting the apis along the lines of http://docs.openstack.org/api/openstack-block-storage/2.0/content/
15:40:13 <shamail> bswartz: I plan to review the code and make an architectural diagram.  I'd love your feedback and hopefully we could post it eventually.
15:40:14 * caitlin56 volunteers to help on vendor doc.
15:40:40 <vbellur> rushiagr: sounds like a good idea
15:40:40 <bswartz> vbellur: oh those are more boilerplate
15:40:57 <rushiagr> shamail: awesome. I'll like to take a look too!
15:41:05 <bswartz> vbellur: we do need those, but not having those doesn't block anybody from making progress during Icehouse I don't beleive
15:41:07 <rushiagr> ^ about arch diagram
15:41:24 <shamail> Yeah, I'll try to share it with everyone via the Manila room.
15:41:31 <vbellur> yeah, i agree but we can have a WIP guide
15:41:32 <bswartz> shamail: excellent
15:42:33 <bswartz> caitlin56: want to post a BP covering what you plan to write?
15:42:51 <rushiagr> I'd definitely help with the docs, but I generally pitch in when I see incompleteness in content, and not when the content is not there at all :P
15:43:02 <bswartz> I think a wiki page would be a good format for a "howto write a manila backend"
15:43:23 <vbellur> bswartz: agree
15:43:40 <shamail> Do we want to focus on writing any new schedulers or improving the current implementation in the ice house time-frame?
15:44:08 <bswartz> shamail: we've inheritted a lot of stuff from cinder already, and I plan to keep stealing their good ideas
15:44:44 <bswartz> I don't want to spend much effort on working on those overlapping areas though when we still have some basic features unimplemented
15:45:01 <bswartz> we need to get the multi-tenant networking working, that's top priority
15:45:13 <caitlin56> bswartz: need exec approval first. Right now I'm still "investigating" manila.
15:45:29 <caitlin56> But doc, that I can do on my own.
15:45:50 <bswartz> second priority is getting backends written and validated so we know that our design is not boneheaded
15:46:10 <bswartz> in 6 months I hope we will be able to go to the next summit and discuss new feature ideas
15:46:16 <bswartz> I think we have plenty to do for the next 6 months
15:46:40 <bswartz> that said, if someone wants to bite off a project, feel free to submit a BP and work on it and we'll try to get it included during Icehouse
15:47:39 <bswartz> okay last call for topics
15:47:45 <bswartz> we have a bit of time left
15:48:08 <bswartz> alright thanks everyone
15:48:16 <vbellur> thanks all
15:48:16 <shamail> Is there a link to a template backed driver?
15:48:32 <bswartz> shamail: there is a generic driver in tree right now
15:48:36 <shamail> See y'all later!
15:48:39 <bswartz> however it's single tenant
15:49:07 <shamail> We'll go ahead and take a look at it.  Thanks again.
15:49:11 <bswartz> once we have multi-tenant networking there will be 2 generic drivers, and the multitenant generic driver will be a better template
15:49:27 <bswartz> okay thanks all for this week
15:49:35 <bswartz> anything else please ping me in #manila
15:49:39 <bswartz> #endmeeting