15:00:56 <bswartz> #startmeeting manila
15:00:57 <openstack> Meeting started Thu Oct 24 15:00:56 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:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:00 <openstack> The meeting name has been set to 'manila'
15:01:22 <bswartz> hello all
15:01:36 <bswartz> #link https://wiki.openstack.org/wiki/ManilaMeetings
15:01:53 <vponomaryov> hi
15:01:56 <caitlin56> hi
15:02:01 <gregsfortytwo> hi
15:02:07 <bswartz> first thing I have some news
15:02:25 <bswartz> I talked to ttx and the TC has not taken up our request for incubation yet
15:02:44 <bswartz> it would seem that I'm supposed to go to the TC meeting and defend the proposal
15:03:03 <bswartz> it's been put on the calendar for Nov 19 (4 weeks away) due to the conference
15:03:16 <bswartz> so this is disappointing
15:03:25 <vbellur> bswartz: yeah
15:03:30 <bswartz> the "show up and defend your propsal" step was not documented
15:03:46 <caitlin56> IRC  meeting? Phone conference? or physical?
15:03:54 <bswartz> IRC meeting
15:04:15 <bswartz> the TC meetings are like all of these meetings, Tueday at 2000 UTC
15:04:21 <caitlin56> Are "friends of the project" encouraged/allowed?
15:04:30 <bswartz> I think they're open to the public
15:04:50 <bill_az_> sorry I'm late - this is about the incubation request ?
15:05:34 <bswartz> bill_az_: yes, it's been delayed again
15:06:10 <bswartz> anyways this gives us more time to lobby behind the scenes -- nothing we can do about the date I don't think, esp w/ the conf coming up so soon
15:06:33 <bill_az_> those in HK can still lobby for the project there
15:06:38 <bswartz> yes
15:06:46 <bswartz> anyways that's all I have in the way of news
15:06:49 <bswartz> #topic status
15:07:09 <bswartz> yportnova: you here?
15:07:28 <vponomaryov> yulia is absent today, so I would inform about progress
15:07:36 <bswartz> vponomaryov: do you have anything?
15:07:39 <bswartz> okay
15:07:48 <vponomaryov> Implementation of Neutron API - in progress (will upload patch no longer than Monday 28.10)
15:08:09 <vponomaryov> 2) Implementation of generic neutron vif driver - in progress - as soon as we want to launch LXC containers on host - we need to provide connectivity to tenant private network like Nova does for VMs. The easier way - copy generic vif driver from Nova nova.virt.libvirt.vif.LibvirtGenericVIFDriver in case of using libvirt for managing LXC container.
15:08:41 <vponomaryov> 3) Implementation of LXC driver - in progress - There is a possibility launching LXC conainers without image - but using hypervisor directly, not libvirt.
15:09:38 <bswartz> vponomaryov: I'm confused about (3)
15:09:42 <navneet> libvirt gives an api layer for diff hypervisors
15:09:44 <caitlin56> Can the APIs support launching on the server end without having an actual hypervisor?
15:09:47 <vponomaryov> and plan is to finish LXC driver and networking
15:09:50 <bswartz> libvirt won't allow creating of LXC containers without an image?
15:10:21 <navneet> bswartz: api should e uniform
15:10:27 <aostapenko> Hi, we discovered an ability to use lxc sharing 1 filesystem with libvirt. it's ok
15:10:41 <aostapenko> hosts filesystem
15:10:50 <vponomaryov> about 3) AFAIK, without image we can create container and than use it with libvirt
15:11:06 <vponomaryov> create container with LXC
15:11:22 <caitlin56> LXC strikes me as a very reasonable approach to doing a vserver for a Linux file server. But not all of us have Linux fileservers.
15:11:27 <bswartz> yes the whole goal here is to provide tenant isolation using linux containers, without going for full virtualization
15:11:55 <bswartz> caitlin56: this is specific to the so-called "LVM driver" for manila
15:12:07 <navneet> bswartz: I guess we should rethink on it
15:12:43 <caitlin56> bswartz: that's fine, but we need to identify this issue for nova team -- and the earlier the better.
15:13:02 <bswartz> what? what does nova have to do w/ it?
15:13:22 <bswartz> It's pretty clear how we can implement a NetApp backend for CIFS/NFS using the proposed model
15:13:53 <caitlin56> Will nova tell the backend to add a VNIC (for a vServer) even if the actual server has no hypervisor?
15:13:55 <bswartz> the main things were trying to get into the codeline are the client APIs to setup the network, and an generic implementation that runs on Linux which we're calling the "LVM driver"
15:14:55 <aostapenko> no. we want to copy functionality from nova. not using nova
15:14:57 <caitlin56> And what I think was just explained is that the LVM Driver can use LXC so that nova is launching a container rather than a full VM.
15:15:04 <bswartz> caitlin56: the interaction should be between manila and neutron directly
15:15:12 <bswartz> I don't see a reason to add any dependency on nova
15:15:16 <navneet> bswartz: suggest u include name...confused which point u addressing
15:15:26 <kendurazzo> Do we need to think about Windows Servers?
15:15:47 <kendurazzo> or just keep it simple at first with one OS?
15:16:11 <bswartz> kendurazzo: we can provide CIFS support using samba inside LXC
15:16:20 <caitlin56> bswartz: so , does our research show that we can tell neutron to provision a VNIC on a baremetal server without relying on a hypervisor?
15:16:35 <bswartz> if someone wants to run manila on Windows they will need to use a different driver
15:17:27 <bswartz> caitlin56: yes it should be possible
15:17:34 <bswartz> I have yet to see a working prototype however
15:18:25 <caitlin56> bswartz: on the Windows issue. The difference between Manila and Cinder is that Manila needs code in the guest itself, correct? Because hypervisor have not defined virt-file-system.
15:18:59 <bswartz> aostapenko/vponomaryov: any word on when we might have a prototype of the code that interacts with neutron to adds a new "virtual NIC" on a physical interface?
15:19:34 <bswartz> caitlin56: that's the difference between the LVM drivers for the two projects
15:19:48 <bswartz> the cinder LVM driver is simple and straightforward
15:20:03 <vponomaryov> bswartz: Info from yulia is next: Implementation of Neutron API is in progress (will upload patch no longer than Monday 28.10)
15:20:06 <bswartz> the manila LVM driver will be more code in order to support multi-tenant
15:20:25 <bswartz> vponomaryov: cool
15:21:06 <bswartz> okay so we're gradually getting the issues sorted out
15:21:37 <bswartz> after HK I hope to quickly get aa referece implementation and some documentation to help others write backends
15:22:04 <bswartz> but first....
15:22:14 <bswartz> #topic feedback on networking BP
15:22:31 <bswartz> #link https://blueprints.launchpad.net/manila/+spec/join-tenant-network
15:22:47 <bswartz> there's been some discussion on this
15:23:15 <bswartz> caitlin56: can you elaborate on your DHCP concerns?
15:23:38 <bswartz> are you thinking that tenants might run their own DHCP inside their tenant network?
15:23:56 <bswartz> that seems odd when IP address assignment is handled by OpenStack
15:24:02 <caitlin56> bswartz: basically, I am worried about disrupting existing tenant networks.
15:24:29 <caitlin56> If a tenant is used to doing their network entirely through their DHCP server, we should let them run their tenant network that way.
15:24:42 <bswartz> how well does multicast work inside a tenant network today?
15:25:25 <bswartz> in my experience multicast support is generally poor, but I haven't tried it w.r.t. openstack
15:26:41 <caitlin56> bswartz:thanks for the update after my temporary glitch there.
15:27:13 <caitlin56> I think we need to clearly define the migration of a network to a tenant network, well probably neutron does.
15:27:52 <bswartz> I think that neutron should always be capable of assigning new IPs to a tenant network
15:28:03 <caitlin56> But a file system is the type of thing where users may be used to having the DHCP server set the associated servers (AD/LDAP/DNS), and we need to provide a complete migration story.
15:28:16 <bswartz> I've never seen a case where neutron cedes control of IP address assignment to a tenant-owned DHCP server
15:28:53 <caitlin56> But you can confirm your IP address with a DHCP server and get the *rest* of your tenant config from it.
15:28:59 <esker> bswartz: I like to suggest asking a representative Neutron core team member to join these meetings
15:29:18 <kendurazzo> in a private cloud implementation, neutron would have to interact with existing DHCP services
15:29:19 <caitlin56> esker: +1
15:29:19 <bswartz> caitlin56: the DNS server configuration is key, but we can require them to supply it to manila, and manila can do the hard work from then on
15:29:56 <bswartz> jcorbin: are you there?
15:30:05 <jcorbin> bswartz: yes
15:30:18 <bswartz> jcorbin: are you on the neutron team?
15:30:46 <jcorbin> bswartz: I am not a neutron core developer. I follow the team. I am still coming up to speed.
15:30:53 <rushiagr> sry, late
15:30:55 <rushiagr> hi all!
15:31:01 <bswartz> we have some questions about the exact workings of IP address assignment in neutron
15:31:13 <bswartz> maybe we need to take an AI to figure this out in the coming week
15:31:24 <bswartz> unless you happen to know the answers
15:31:41 <jcorbin> bswartz: I would have to investigate. I have not looked into IP assignments.
15:32:09 <bswartz> jcorbin: do you know if neutron has a mode where IP address assignment is owned by a tenant-controlled DHCP server?
15:33:06 <bswartz> we can table this until next week
15:33:23 <bswartz> it's an interesting concern, but I don't feel like it's a showstopper
15:33:34 <jcorbin> bswartz: Neutron will configure a DHCP server on each tenant network. I don't know what the options are for controlling this. There is also an extension to the Neutron API to send options to the DHCP server.
15:33:43 <bswartz> caitlin56: did you have any other issues w/ the proposal?
15:33:54 <caitlin56> bswartz: the potentially critical issue is the update of tenant specific DNS from tenant specific DHCP.
15:34:08 <caitlin56> bswartz: otherwise it looked good.
15:34:49 <bswartz> caitlin56: it doesn't seem unreasonable to simply ignore DHCP and require that the tenant supplies the DNS server IP to us directly -- they must supply the other parameters in any case
15:35:46 <caitlin56> The issue is registering dynamic IP addresses with the DNS server within the tenant network. You can work around giving the DNS server IP addresses out via manila.
15:36:28 <bswartz> if what jcorbin says is accurate, then neutron maintains control of the DHCP infrastructure, and must have ways to reserve certain IPs as static
15:36:31 <caitlin56> But telling customers that they have to enter every address given out by neutron in their DNS server will not get favorable responses.
15:37:12 <bswartz> caitlin56: that's not at all what I'm suggesting
15:37:19 <bswartz> I think it will be clearer when we have some working code
15:37:41 <bswartz> we can keep the discussion going on the BP
15:37:47 <bswartz> and follow up on this next week
15:37:53 <bswartz> on to more urgent stuff:
15:37:59 <bswartz> #topic conference
15:38:26 <bswartz> so people have been asking what kind of meetings we might have in HK
15:38:41 <bswartz> I still plan to do an unconference session, but I have another idea too
15:39:23 <bswartz> since the main goal of the meeting is just to get to know eachother on this new project, we should have a social meeting
15:39:40 <bswartz> I'm proposing something around 5-6:30PM
15:39:42 <bswartz> on tuesday
15:40:03 <bswartz> maybe 5:30-7PM (depending on when the sessions wrap up)
15:40:14 <bswartz> we can reserve some space and I'll send out the location
15:40:23 <bswartz> I'd need you all to RSVP so I know how much space is needed
15:40:40 <bswartz> please RSVP to bswartz@netapp.com
15:40:59 <bswartz> I'll send out email reminders in case anyone misses this meeting
15:41:16 <bswartz> how does that sound?
15:41:31 <esker> bswartz:  what about a formal design summit session?
15:41:32 <bswartz> tuesday cocktail hour sound like a good time for a social gathering?
15:41:48 <bswartz> esker: out of the question until we're formally recognized as a project
15:41:57 <rushiagr> +1
15:42:17 * rushiagr reminds himself he is not completely sure of his presence
15:42:23 <caitlin56> +1
15:42:38 <bill_az_> do you know when the unconference meeting(s) will be?
15:43:08 <bswartz> bill_az_: I can't reserve a time/place until I'm standing in front of the whiteboard in HK -- that's how unconference sessions work
15:43:10 <bill_az_> I'm not going to be in HK, but will have someone else - probably Avishay - attend
15:43:18 <kendurazzo> +1
15:43:40 <bswartz> bill_az_: okay I'll make sure he's invited to everything we do
15:43:48 <bill_az_> bswartz:  thanks
15:44:49 <bswartz> okay so 5pm-6:30pm tuesday is the plan -- we'll get a space large enough to accomdate the folks who RSVP
15:45:25 <bswartz> additionally I'll do an unconference session at a time that doesn't conflict w/ cinder or nova/neutron storage related meetings
15:45:35 <bswartz> #topic open discussion
15:45:41 <bswartz> anything else to bring up?
15:45:55 <rushiagr> any progress on the incubation request?
15:45:56 <bswartz> we're just 12 days away from teh conference
15:46:00 <rushiagr> or is this already discussed?
15:46:05 <bswartz> rushiagr: read the logs :-(
15:46:39 <bswartz> short answer -- the decision is delayed another 4 weeks
15:47:12 <rushiagr> oh
15:47:14 <esker> rushiagr: due to a double-secret, undocumented requirement for incubation consideration
15:47:14 <rushiagr> :(
15:47:24 <bswartz> okay if no one has anything else we'll wrap up
15:47:35 <bswartz> #endmeeting