15:01:06 <bswartz> #startmeeting manila
15:01:07 <openstack> Meeting started Thu Oct 31 15:01:06 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:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:11 <openstack> The meeting name has been set to 'manila'
15:01:38 <bswartz> hey guys
15:01:45 <vponomaryov> hi
15:01:48 <bswartz> last meeting before HK
15:01:48 <aostapenko> hi
15:01:52 <shamail> Hello
15:02:06 <glenng1> Whaa Hoo
15:02:11 <bswartz> #link https://wiki.openstack.org/wiki/ManilaMeetings
15:02:43 <bswartz> so the main thing is the conference
15:02:49 <bswartz> #topic conference
15:03:31 <bswartz> for those of you attending the conference, we've settled on 5:30 tuesday for our meetup
15:03:48 <bswartz> I still need you to RSVP if you haven't already: bswartz@netapp.com
15:04:28 <bswartz> The location is not set yet, but we will find a nice corner of the hotel bar and reserve it for 90 minutes or so
15:04:57 <shamail> Great, look forward to it.
15:05:23 <bswartz> I'll get drinks for anyone who's been coming to these meetings
15:05:45 <bswartz> additionally, I'll try to fit in an unconference sessions
15:05:48 <bswartz> session*
15:06:19 <bswartz> I still need to go over the schedule and find a timeslot that doesnt' conflict
15:06:41 <shamail> bswartz: What will be the method of sending out additional sessions? Email?
15:06:42 <bswartz> overall I'm excited about hte conference -- many of the summit sessions look interesting
15:07:18 <bswartz> well for the tuesday get together I'll be sending out the location to people who've RSVPd
15:07:40 <bswartz> Jeff Oneal will get to HK early and reserve a place
15:07:58 <bswartz> for the unconference session it will be posed on the whiteboard near the unconference rooms
15:08:09 <shamail> bswartz: Okay, thanks!
15:08:33 <bswartz> I'll do that first thing tuesday so if it isn't posted tuesday morning then it means I probably couldn't find a time that works
15:09:51 <bswartz> anyone have any other questions about our plans for HK?
15:10:10 <bswartz> they're very modest this time around -- expect more for the J-release conference
15:10:36 <bswartz> okay
15:10:39 <bswartz> #topic dev status
15:10:59 <bswartz> so I've learned a few things about linux containers
15:11:21 <bswartz> (1) they need their own filesystem root, they cannot share the filesystem root with the parent OS
15:12:06 <bswartz> (2) LXC is actually a fairly immature linux container implementation -- OpenVZ is another implementation that uses the same kernel feature (containers) and is much more production ready
15:12:47 <vponomaryov> Actually, NFSkernel server does not work in OpenVZ too
15:12:51 <bswartz> If we do go down the linux containers path, I think we'll lean towards OpenVZ over LXC -- they're both supported by libvirt btw
15:13:00 <bswartz> oh that's a third thing
15:13:08 <caitlin56> A key test of these containers is whether you can do per tenant DNS and DHCP.
15:13:19 <bswartz> (3) You can't use the Kernel NFS server with linux containers, because you only get 1 kernel
15:13:43 <bswartz> thanks vponomaryov
15:13:59 <bswartz> caitlin56: I'm fairly certain that won't be an issue, but it's worth confirming
15:14:13 <bswartz> there is a user-space NFS server that allows us to overcome the 3rd issue
15:14:26 <bswartz> but the first issue is the one that concerns me most
15:14:46 <caitlin56> bswartz: my research says that it is possible, but not the default configuration with most of them.
15:14:57 <aostapenko> and user nfs server supports only nfs3
15:15:09 <gregsfortytwo1> bswartz: you're looking at Ganeti?
15:15:46 <bswartz> if the LVM driver for Manila is going to rely on a specially-crafted root filesystem, then we're going to have to maintain a little "distribution" of sorts including all the binaries needed to run the container
15:15:52 <caitlin56> aosstapenko: this is a solution for testing, right? nfs3 is good enough.
15:16:40 <bswartz> if we end up having to maintain a distro, it's probably better to go with something off the shelf and fully virtualize it
15:16:54 <gregsfortytwo1> err, Ganesha I mean
15:17:13 <bswartz> the point of the LVM driver is to provide full functionality in a software-only mode -- to be a reference implementation
15:17:48 <bswartz> full virtualization is less efficient than containers but it seems that containers don't buy us much other than efficiency
15:18:20 <bswartz> and with all the limitations, I think people would be happier with full virtualization and access to the kernel NFS server, etc
15:18:41 <vponomaryov> bswartz: maybe we should do containers support as more flexibility, fot those, who will use Samba, etc ?
15:19:16 <bswartz> We could, for example, find a really stripped-down version of Debian, add some scripts to it, and use that as our NFS/CIFS server
15:19:53 <bswartz> if we write the scripts right, then perhaps we could even leave it up to the admin to find his own distro (for people who prefer redhat, for example)
15:20:41 <bswartz> vponomaryov: containers may still be a valid backend, but I think from the manila side we want to limit the complexity
15:20:53 <bswartz> gregsfortytwo1: sorry I'm not familiar with ganesha
15:21:10 <gregsfortytwo1> oh, you said user-space nfs server, it's the only one of those I'm familiar with
15:22:09 <bswartz> gregsfortytwo1: is that the same as unfs3?
15:22:25 <aostapenko> actually it is unfs3
15:22:42 <gregsfortytwo1> don't think so…looks like https://github.com/nfs-ganesha/nfs-ganesha/wiki is the homepage?
15:22:51 <bswartz> hmm
15:23:06 <bswartz> I wonder what you get when you apt-get install nfs-user-server
15:23:16 <aostapenko> nothing
15:23:24 <vponomaryov> bswartz: nfs-user-server is absent in repos
15:23:31 <aostapenko> we need to get the source
15:23:33 <vponomaryov> and it is different from uns3
15:23:45 <bswartz> vponomaryov: it existed back in 8.04
15:23:54 <bswartz> perhaps it got removed
15:24:05 <gregsfortytwo1> yeah, looks like removed from Debian in 2009
15:24:12 <gregsfortytwo1> http://packages.qa.debian.org/n/nfs-user-server.html
15:24:57 <bswartz> in any case, my feeling is that the nfs-kernel-server is more feature rich and better maintained
15:24:58 <gregsfortytwo1> anyway, Ganesha is interesting to me because it has a pluggable interface to its backing filesystem, but I don't know anything else about it
15:25:56 <caitlin56> So the real tradeoff is NFS-kernel under a VM versus userland NFS with containers. Given the goals of the project, I suspect that VMs make more sense. But either would work.
15:26:24 <bswartz> but more important than that, full virtualization will probably be easier to implement and easier to maintain
15:27:38 <caitlin56> agreed VMs simpler than containers, nfs-kernel simpler than user-mode kernel.
15:27:48 <bswartz> if we write the LVM driver to assume a fully virtualized server (under nova) then all we need to do is define the software that must exist inside the VM, and define the management interface between manila and that
15:28:20 <bswartz> I'm undecided on whether we should specify a Linux distro or remain agnostic about that
15:29:34 <vponomaryov> bswartz: I think, it will be customer friendly to have image in glance special for that
15:30:02 <bswartz> vponomaryov: well customers (end users) probably will never see the VMs directly
15:30:10 <bswartz> these real customer of manila is the administrator
15:30:19 <caitlin56> bswartz: I think you want to spec a Linux distro with at least these versions of these packages.
15:30:36 <bswartz> and the administrator may want freedom to use a different image
15:31:12 <bswartz> some people have strong feelings -- I can't imagine redhat running an debian-derivative, and I can't imagine canonical running a redhat-derivative
15:31:33 <bswartz> I don't want to get in the middle of that
15:31:39 <jcorbin> bswartz: are you suggesting that the reference implementation of the Manila server would be running on a VM provisioned by Nova?
15:32:00 <bswartz> jcorbin: that seems to be the path of least resistence
15:32:16 <bswartz> jcorbin: and it always fits very nicely within the design of openstack
15:32:32 <bswartz> s/always/actually/
15:32:33 <jcorbin> bswarz: I like that because then the network will be provisioned for you. Agree with path of least resistence
15:33:16 <bswartz> okay so that's a nice segue into talking about the network stuff again
15:33:28 <bswartz> yportnova: you here?
15:33:41 <vponomaryov> no, she is absent
15:33:52 <bswartz> vponomaryov: do you have an update
15:34:10 <bswartz> how is the prototype for the neutron API calling code
15:34:24 <vponomaryov> Actually, we had an update with containers, which are already discussed, and one another thing is that
15:34:55 <vponomaryov> network code for quantum is blocked by driver with/out containers or full virtualisation
15:35:11 <vponomaryov> *of
15:35:40 <bswartz> vponomaryov: I'd like to model the network configuration code around what's most likely to work with real hardware backends
15:35:50 <bswartz> because those are going to be less flexible than the software backend
15:36:19 <bswartz> We need to prove that the design works for both software and multiple hardware backends to have confidence, of course
15:36:34 <caitlin56> I'm trying to gather a set of requirements from our field engineers about what real customers need to do for "network" configuration to support NFS and CIFS.
15:37:10 <caitlin56> I'll post once I have gathered, but I am concerned that the neutron dhcp-agent does not look to be adequate for this use. It only assigns IP addresses.
15:37:18 <caitlin56> and gateway.
15:37:36 <bswartz> caitlin56: netapp devices don't use DHCP at all -- it's all static configuration
15:37:54 <shamail> same.
15:37:54 <bswartz> manila will need to have the capability to statically configure backends
15:37:59 <caitlin56> But what about your clients?
15:38:16 <bswartz> the client is the one giving us the information
15:38:35 <bswartz> the client supplies the DNS server IP, the AD domain name, the AD credentials, etc
15:38:47 <caitlin56> You don't have clients that are getting the AD or LDAP server from the DHCP server?
15:38:53 <bswartz> in most cases OpenStack won't even have that information
15:39:19 <bswartz> typically clients get teh DNS server from DHCP and find everything else through DNS
15:39:38 <caitlin56> That might be good enough.
15:40:11 <bswartz> if there are backends that can't work without DHCP then we'll need to look into how to support those
15:40:55 <bswartz> but right now I'm under the impression that DHCP not a critical piece of intrastructure, outside of assigning IPs/netmasks/gateway/DNS
15:41:12 <shamail> This part of the networking discussion is discussing services, we assume base connectivity to the tenant's network is established?  Sorry, missed last week.
15:41:26 <bswartz> shamail: yes
15:41:53 <bswartz> we're prototyping the code that manila will use to call neutron and wire in a storage controller directly to a tenant VLAN
15:42:39 <bswartz> vponomaryov: it may make sense to base the prototype on a netapp backend rather than the LVM backend, so the 2 projects can proceed in parallel
15:43:06 <caitlin56> Telling tenants that a) they need a static IP for their openstack launched clients and b) that they find other services on their tenant network via DNS is probably acceptable.
15:44:11 <bswartz> caitlin56: My intent is that neutron will still own the IP assigning, but the backend will be statically configured
15:44:53 <bswartz> the clients shouldn't need to do anything different
15:45:06 <jcorbin> bswartz: With the reference port, with LVM and no HW storage controller,I would think that the VM is already wired into the tenant network when it is created. You just specify the networks you want to configure the Manila VM to. Is that correct?
15:45:25 <bswartz> unless perhaps they're running an AD server inside the cloud -- that would need a static IP beacuse AD servers changing IPs seems like bad news
15:45:32 <caitlin56> As I understand neutron, you can't just fire off a VM that has no IP address before the tenant DHCP gives it to them.
15:46:16 <bswartz> jcorbin: yeah
15:46:21 <caitlin56> THe VM might not *know* its IP address until it asks for it via DHCP, but it was determined before the VM launched.
15:47:35 <bswartz> okay I'm getting confused here
15:47:49 <bswartz> we have 2 topics going on I think
15:47:57 <bswartz> the LVM backend and the network config
15:48:00 <shamail> sorry, disconnected.
15:48:02 <jcorbin> caitlin56: I see the problem. I will see if there is a way to statically allocate a VM to a tenant network.
15:48:04 <caitlin56> Difference is very technical. DHCP has rules on how quickly an IP address can be reassigned. Neutron does not.
15:48:14 <bswartz> for the purposes of network config, let's assume a hardware based backend with static configuraiton
15:48:51 <caitlin56> It's a minor distinction that no customer should object to, but one that they should be warned about.
15:49:10 <shamail> bswartz: that will probably provide the most flexibility in accommodating numerous options.
15:49:22 <bswartz> is neutron not able to give permanent leases out?
15:49:59 <bswartz> if it isn't then I can see how that presents a problem
15:50:36 <caitlin56> Neutron leases can be changed by admin at any time. Not exactlythe same rules as for DHCP dynamic leases.
15:50:46 <caitlin56> But the admin can choose to follow those rules.
15:51:01 <jcorbin> bswartz: I can look into that. I would think that the Ironic project would want static IPs for dedicated instances.
15:51:10 <bswartz> vponomaryov: have you looked at obtaining an IP address from neutron on a permanent basis?
15:51:21 <bswartz> jcorbin: thanks, I agree
15:51:42 <vponomaryov> bswartz: I haven't info about this
15:51:55 <bswartz> okay
15:52:03 <bswartz> some more stuff to look into
15:52:15 <bswartz> so I will be busy next week, as will many of you I imagine
15:52:29 <caitlin56> It's more an issue for anyone who was *relying* on dynamic addresses. But those are pretty rare.
15:52:38 <bswartz> we'll cancel next week's meeting right now
15:52:52 <bswartz> and plan to meet again on 14 Nov
15:53:02 <bswartz> #topic open discussion
15:53:31 <caitlin56> The 14 Nov meeting, what time will that be for those of us on the west coast?
15:53:50 <bswartz> anything else to talk about before we head off to HK?
15:54:16 <vponomaryov> bswartz: we have several slides for, we will send it in email
15:54:21 <iccha> hey the qonos nodes in prod have 75 workers, would be great if we could merge these prs to reflect state in prdocution:
15:54:25 <iccha> https://github.rackspace.com/O3Eng/region-ord/pull/102
15:54:33 <bswartz> caitlin56: thanks for the reminder
15:54:46 <iccha> https://github.rackspace.com/O3Eng/region-ord/pull/68
15:55:01 <bswartz> so because DST ends for those of us who are US-based, this meeting remains at 1500 UTC
15:55:10 <iccha> https://github.rackspace.com/O3Eng/region-dfw/pull/77
15:55:27 <iccha> https://github.rackspace.com/O3Eng/region-dfw/pull/48
15:55:41 <bswartz> that means it will be 1 hour earlier on your calendar if you're US-based, until DST kicks in again on 2014 March 10
15:55:50 <iccha> sorry wrong window
15:56:07 <caitlin56> bswart: not a problem for me. But most west coast based engineers are more likely to *still* be up at 7:00 AM than to have woken up.
15:56:27 <caitlin56> You might want to see if you can get a better time slot.
15:57:04 <bswartz> caitlin56: I knew about this issue when I scheduled the meeting -- it's an unavoidable problem when trying to schedule these worldwide meetings
15:57:19 <bswartz> I would have chosen a later timeslot but they're all taken
15:58:11 <caitlin56> ok, might not be a problem. Everyone willing to do irc at 8:00 AM might be able to do 7:00.
15:58:21 <bswartz> unfortunately our west coast friends will need to wake up early for a couple of months
15:58:57 <bswartz> vponomaryov: I saw the set of slides you sent out this morning
15:59:14 <bswartz> vponomaryov: if you have more I'd love to see them
15:59:24 <bswartz> I don't have anything else for today
15:59:29 <bswartz> and somehow we used the whole hour
15:59:36 <vponomaryov> bswartz: ok
15:59:36 <bswartz> thanks everyone
15:59:44 <bswartz> see you in 2 weeks if I don't see you in HK
15:59:55 <aostapenko> thank you, bye
15:59:59 <shamail> Thanks.  Take care everyone.
16:00:03 <bswartz> remembe to RSVP to bswartz@netapp.com if you're coming to our meeting 5:30PM on tuesday
16:00:10 <vponomaryov> bye
16:00:12 <bswartz> #endmeeting