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