15:02:25 <bswartz> #startmeeting manila
15:02:26 <openstack> Meeting started Thu Mar 27 15:02:25 2014 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:29 <openstack> The meeting name has been set to 'manila'
15:02:34 <bswartz> hello all
15:02:37 <vponomaryov> hi
15:02:40 <scottda> Hi
15:02:42 <yportnova> hi
15:02:47 <Guest27670> hi
15:02:57 <csaba> hi
15:02:59 <bswartz> Like last week I don't have too much to cover today
15:02:59 <rraja> hi
15:03:16 <bswartz> oh wow a bunch of folks are back today!
15:03:36 <bill_az> Hi all
15:03:43 <bswartz> I'd like to start with the dev status and then dive into more specific topics afterwards
15:03:47 <bswartz> #topic dev status
15:03:52 <vponomaryov> Dev status:
15:04:01 <vponomaryov> 1) Horizon
15:04:01 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/horizon-integration
15:04:01 <vponomaryov> code: #link https://github.com/NetApp/horizon/tree/manila
15:04:01 <vponomaryov> status: work in progress
15:04:11 <vponomaryov> 2) Implementation of activation api into multitenant drivers
15:04:11 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/share-network-activation-api
15:04:11 <vponomaryov> 1.1) Cmode driver, #link https://review.openstack.org/#/c/81744/
15:04:11 <vponomaryov> 1.2) Generic driver, #link https://review.openstack.org/#/c/81808/
15:04:11 <vponomaryov> status: implemented, merged.
15:04:24 <vponomaryov> 3) Quota for activated share-networks
15:04:24 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/quota-for-share-networks
15:04:24 <vponomaryov> gerrit: #link https://review.openstack.org/#/c/78974/
15:04:24 <vponomaryov> gerrit: #link https://review.openstack.org/#/c/78979/
15:04:24 <vponomaryov> status: implemented, merged.
15:04:40 <vponomaryov> TODO:
15:04:40 <vponomaryov> 1) Finish "Horizon" extension for Manila
15:04:46 <vponomaryov> Open Item:
15:04:46 <vponomaryov> 1) Critical bug, #link https://bugs.launchpad.net/manila/+bug/1297854
15:04:53 <vponomaryov> thats all
15:05:12 <bswartz> critical bug? ouch
15:05:20 <bswartz> I haven't seen that one
15:05:31 <bswartz> thanks vponomaryov
15:05:59 <bswartz> can you fill us in on the issue with this SSH bug?
15:06:07 <bswartz> is it a mystery?
15:06:16 <vponomaryov> bswartz: its Neutron
15:06:43 <vponomaryov> we found out, that neutron can not set more than 5 ips for the port
15:06:56 <vponomaryov> so we can use only 5 activated share-networks
15:07:05 <bswartz> wait
15:07:13 <bswartz> I thought a port was an IP
15:07:27 <bswartz> two different IPs should be two different ports, shouldn't they?
15:07:33 <vponomaryov> no
15:07:52 <vponomaryov> port, as entity in Neutron it has assigned fixed ips
15:08:28 <vponomaryov> anyway, there is solution for it
15:08:38 <bswartz> okay I'm confused
15:08:50 <bswartz> I need to spend some more time hacking on neutron
15:09:06 <vponomaryov> we face this issue, because for each share_network we use separate subnet with /29 mask
15:09:25 <vponomaryov> so solution - use same subnet
15:10:07 <bswartz> use same subnet for what?
15:10:16 <bswartz> for multiple tenants?
15:10:23 <vponomaryov> port, that switched to manila service network
15:10:23 <bswartz> that wouldnt' create a security issue
15:10:43 <vponomaryov> so, its ok, if wo so?
15:10:44 <bswartz> s/wouldnt/would/
15:10:54 <vponomaryov> *if we do so
15:11:59 <bswartz> I'm not clear enough on the problem or the proposed solution to make a decision
15:12:25 <bswartz> I'll take a look at it and we can follow up
15:12:30 <vponomaryov> ok
15:12:42 <bswartz> if anyone else gets what the issue is please feel free to chime in
15:13:01 <bswartz> regarding the rest of the stuff, we did merge several things this week
15:13:26 <bswartz> we're getting closer to having all the features we wanted to have before atlanta
15:13:56 <bswartz> since we have csaba today, is there any update on the image?
15:14:22 <csaba> yep
15:14:42 <csaba> it works now as service vm :)
15:14:50 <bswartz> completely done?
15:14:54 <csaba> no
15:14:59 <csaba> there is an annoying issue
15:15:19 <csaba> the image needs a flavor with 256m ram to boot up
15:15:38 <bswartz> that's the minimum? or you need exactly that much?
15:16:06 <csaba> that's because the technique of building the initramfs is just simply to replicate the rootfs as initramfs
15:16:28 <bswartz> and the rootfs you've created is quite large?
15:16:33 <csaba> which is not a problem with original minimalistic cirros... but has this effect for us
15:17:00 <csaba> well I progressed with 2 powers so 128 is not yet enough, 256 is enough
15:17:32 <bswartz> csaba: do you know enough about the linux boot process to change it so that it doesn't put the whole rootfs in ram?
15:17:46 <csaba> that's what I'm working on now
15:17:57 <bswartz> that's fun stuff
15:17:57 <csaba> there is actually a simple way to get at that
15:18:03 <bswartz> thanks for working on it
15:18:09 <csaba> ie. just don't use initrd
15:18:36 <bswartz> if no initrd is needed then why does cirros bother?
15:18:39 <csaba> the drawback that then the block device's name (/dev/vda1) has to be hard-wired into the boot confif
15:18:49 <csaba> config
15:19:18 <csaba> which might be different if virtualization config/platform is different
15:19:26 <bswartz> oh I see
15:19:45 <csaba> so I think the proper solution is to build a trimmed down initrd
15:19:46 <bswartz> yeah it would be /dev/sda1 on /dev/hda1 under another hypervisor
15:19:56 <csaba> that's what I'm working on now
15:20:00 <bswartz> okay cool
15:20:31 <bswartz> rraja: are you still working on a gateway driver for gluster?
15:20:32 <csaba> anyway the current image is available here: http://people.redhat.com/chenk/cirros/cirros-generic-svm-438358f.qcow2
15:20:56 <csaba> so it's expected to work if beefy service flavor is used
15:21:03 <bswartz> csaba: ty
15:21:15 <csaba> made off of this branch https://github.com/csabahenk/cirros/tree/manila-service-generic-devel
15:21:41 <bswartz> all of the generic driver refactoring is merged I think -- the point of that work was to enable the gateway-based multitenancy stuff
15:21:43 <csaba> I'll consolidate it into  https://github.com/csabahenk/cirros/tree/manila-service where usually the stuff goes
15:21:43 <rraja> bswarts: not really. i've been helping csaba with fixing the bugs in the cirros image and testing it.
15:21:49 <bswartz> I personally haven't been spending time on it
15:22:03 <bswartz> okay, do you still want to own that rraja?
15:22:14 <bswartz> or do we need more people looking at that?
15:23:16 <rraja> bswartz: i definitely don't mind with someone else taking it up.
15:23:19 <vponomaryov> bswartz: we already have gateway with NOVA's service vm
15:23:41 <vponomaryov> it can be used by any driver as generic do
15:23:51 <bswartz> vponomaryov: what about the backend though?
15:24:40 <vponomaryov> I mean backend driver can use service_instance module to attach its volumes
15:24:55 <bswartz> the point of the gateway driver is to allow a manila backend to provide a share on one network and have the gateway reexport that into the tenant network securely
15:25:32 <bswartz> if the service VM has all the parts needed then we need to make sure the APIs allow us to automate the whole process
15:26:46 <bswartz> vponomaryov: you and I should spend some time walking through that too
15:27:08 <vponomaryov> bswartz: agree
15:27:10 <bswartz> #topic open discussion
15:27:19 <bswartz> okay is there anything else someone wanted to discuss today?
15:27:19 <rraja> bswartz: our plan for now is to get a multi-tenant glusterfs driver working using the generic service VM approach.
15:27:37 <bswartz> rraja: yeah that was my understanding
15:27:49 <bswartz> I want to make sure we have a reusable model for that though
15:27:55 <bswartz> I don't want all the hard work to be inside the driver
15:28:46 <csaba> like having a data structure that describes the service vm instrumentalization?
15:29:15 <csaba> and just pass that on to the service vm managing component?
15:29:57 <bswartz> csaba: yeah I think so -- the driver should be able to let manila know that it doens't natively support conneting to tenant networks and the work of creating the service VM could be handled by the manager
15:29:59 <csaba> instead of implenting event logic in each service vm flavor..
15:30:09 <bswartz> from the tenant side, the experience should be the tsame
15:30:11 <bswartz> same
15:30:33 <bswartz> manila should just know when it needs to create a service VM and when it doesn't
15:30:52 <vponomaryov> bswartz: it is already know it
15:30:59 <vponomaryov> with activation API
15:31:03 <bswartz> and there needs to be a communication path between the manager and the driver or the VM and the driver so that it can access the actual storage
15:31:22 <bswartz> okay so vponomaryov is clearly thinking ahead of me lol
15:32:03 <bswartz> I'll try some of this out in my lab and see how well it works
15:32:12 <bswartz> it's been a while since I spent time on that
15:32:26 <bswartz> anything else for today?
15:33:08 <bswartz> all right thanks everyone
15:33:14 <vponomaryov> thanks
15:33:15 <bswartz> #endmeeting