15:00:56 #startmeeting manila 15:00:57 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:00 The meeting name has been set to 'manila' 15:01:22 hello all 15:01:36 #link https://wiki.openstack.org/wiki/ManilaMeetings 15:01:53 hi 15:01:56 hi 15:02:01 hi 15:02:07 first thing I have some news 15:02:25 I talked to ttx and the TC has not taken up our request for incubation yet 15:02:44 it would seem that I'm supposed to go to the TC meeting and defend the proposal 15:03:03 it's been put on the calendar for Nov 19 (4 weeks away) due to the conference 15:03:16 so this is disappointing 15:03:25 bswartz: yeah 15:03:30 the "show up and defend your propsal" step was not documented 15:03:46 IRC meeting? Phone conference? or physical? 15:03:54 IRC meeting 15:04:15 the TC meetings are like all of these meetings, Tueday at 2000 UTC 15:04:21 Are "friends of the project" encouraged/allowed? 15:04:30 I think they're open to the public 15:04:50 sorry I'm late - this is about the incubation request ? 15:05:34 bill_az_: yes, it's been delayed again 15:06:10 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 those in HK can still lobby for the project there 15:06:38 yes 15:06:46 anyways that's all I have in the way of news 15:06:49 #topic status 15:07:09 yportnova: you here? 15:07:28 yulia is absent today, so I would inform about progress 15:07:36 vponomaryov: do you have anything? 15:07:39 okay 15:07:48 Implementation of Neutron API - in progress (will upload patch no longer than Monday 28.10) 15:08:09 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 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 vponomaryov: I'm confused about (3) 15:09:42 libvirt gives an api layer for diff hypervisors 15:09:44 Can the APIs support launching on the server end without having an actual hypervisor? 15:09:47 and plan is to finish LXC driver and networking 15:09:50 libvirt won't allow creating of LXC containers without an image? 15:10:21 bswartz: api should e uniform 15:10:27 Hi, we discovered an ability to use lxc sharing 1 filesystem with libvirt. it's ok 15:10:41 hosts filesystem 15:10:50 about 3) AFAIK, without image we can create container and than use it with libvirt 15:11:06 create container with LXC 15:11:22 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 yes the whole goal here is to provide tenant isolation using linux containers, without going for full virtualization 15:11:55 caitlin56: this is specific to the so-called "LVM driver" for manila 15:12:07 bswartz: I guess we should rethink on it 15:12:43 bswartz: that's fine, but we need to identify this issue for nova team -- and the earlier the better. 15:13:02 what? what does nova have to do w/ it? 15:13:22 It's pretty clear how we can implement a NetApp backend for CIFS/NFS using the proposed model 15:13:53 Will nova tell the backend to add a VNIC (for a vServer) even if the actual server has no hypervisor? 15:13:55 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 no. we want to copy functionality from nova. not using nova 15:14:57 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 caitlin56: the interaction should be between manila and neutron directly 15:15:12 I don't see a reason to add any dependency on nova 15:15:16 bswartz: suggest u include name...confused which point u addressing 15:15:26 Do we need to think about Windows Servers? 15:15:47 or just keep it simple at first with one OS? 15:16:11 kendurazzo: we can provide CIFS support using samba inside LXC 15:16:20 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 if someone wants to run manila on Windows they will need to use a different driver 15:17:27 caitlin56: yes it should be possible 15:17:34 I have yet to see a working prototype however 15:18:25 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 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 caitlin56: that's the difference between the LVM drivers for the two projects 15:19:48 the cinder LVM driver is simple and straightforward 15:20:03 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 the manila LVM driver will be more code in order to support multi-tenant 15:20:25 vponomaryov: cool 15:21:06 okay so we're gradually getting the issues sorted out 15:21:37 after HK I hope to quickly get aa referece implementation and some documentation to help others write backends 15:22:04 but first.... 15:22:14 #topic feedback on networking BP 15:22:31 #link https://blueprints.launchpad.net/manila/+spec/join-tenant-network 15:22:47 there's been some discussion on this 15:23:15 caitlin56: can you elaborate on your DHCP concerns? 15:23:38 are you thinking that tenants might run their own DHCP inside their tenant network? 15:23:56 that seems odd when IP address assignment is handled by OpenStack 15:24:02 bswartz: basically, I am worried about disrupting existing tenant networks. 15:24:29 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 how well does multicast work inside a tenant network today? 15:25:25 in my experience multicast support is generally poor, but I haven't tried it w.r.t. openstack 15:26:41 bswartz:thanks for the update after my temporary glitch there. 15:27:13 I think we need to clearly define the migration of a network to a tenant network, well probably neutron does. 15:27:52 I think that neutron should always be capable of assigning new IPs to a tenant network 15:28:03 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 I've never seen a case where neutron cedes control of IP address assignment to a tenant-owned DHCP server 15:28:53 But you can confirm your IP address with a DHCP server and get the *rest* of your tenant config from it. 15:28:59 bswartz: I like to suggest asking a representative Neutron core team member to join these meetings 15:29:18 in a private cloud implementation, neutron would have to interact with existing DHCP services 15:29:19 esker: +1 15:29:19 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 jcorbin: are you there? 15:30:05 bswartz: yes 15:30:18 jcorbin: are you on the neutron team? 15:30:46 bswartz: I am not a neutron core developer. I follow the team. I am still coming up to speed. 15:30:53 sry, late 15:30:55 hi all! 15:31:01 we have some questions about the exact workings of IP address assignment in neutron 15:31:13 maybe we need to take an AI to figure this out in the coming week 15:31:24 unless you happen to know the answers 15:31:41 bswartz: I would have to investigate. I have not looked into IP assignments. 15:32:09 jcorbin: do you know if neutron has a mode where IP address assignment is owned by a tenant-controlled DHCP server? 15:33:06 we can table this until next week 15:33:23 it's an interesting concern, but I don't feel like it's a showstopper 15:33:34 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 caitlin56: did you have any other issues w/ the proposal? 15:33:54 bswartz: the potentially critical issue is the update of tenant specific DNS from tenant specific DHCP. 15:34:08 bswartz: otherwise it looked good. 15:34:49 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 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 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 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 caitlin56: that's not at all what I'm suggesting 15:37:19 I think it will be clearer when we have some working code 15:37:41 we can keep the discussion going on the BP 15:37:47 and follow up on this next week 15:37:53 on to more urgent stuff: 15:37:59 #topic conference 15:38:26 so people have been asking what kind of meetings we might have in HK 15:38:41 I still plan to do an unconference session, but I have another idea too 15:39:23 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 I'm proposing something around 5-6:30PM 15:39:42 on tuesday 15:40:03 maybe 5:30-7PM (depending on when the sessions wrap up) 15:40:14 we can reserve some space and I'll send out the location 15:40:23 I'd need you all to RSVP so I know how much space is needed 15:40:40 please RSVP to bswartz@netapp.com 15:40:59 I'll send out email reminders in case anyone misses this meeting 15:41:16 how does that sound? 15:41:31 bswartz: what about a formal design summit session? 15:41:32 tuesday cocktail hour sound like a good time for a social gathering? 15:41:48 esker: out of the question until we're formally recognized as a project 15:41:57 +1 15:42:17 * rushiagr reminds himself he is not completely sure of his presence 15:42:23 +1 15:42:38 do you know when the unconference meeting(s) will be? 15:43:08 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 I'm not going to be in HK, but will have someone else - probably Avishay - attend 15:43:18 +1 15:43:40 bill_az_: okay I'll make sure he's invited to everything we do 15:43:48 bswartz: thanks 15:44:49 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 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 #topic open discussion 15:45:41 anything else to bring up? 15:45:55 any progress on the incubation request? 15:45:56 we're just 12 days away from teh conference 15:46:00 or is this already discussed? 15:46:05 rushiagr: read the logs :-( 15:46:39 short answer -- the decision is delayed another 4 weeks 15:47:12 oh 15:47:14 rushiagr: due to a double-secret, undocumented requirement for incubation consideration 15:47:14 :( 15:47:24 okay if no one has anything else we'll wrap up 15:47:35 #endmeeting