15:01:27 <bswartz> #startmeeting manila
15:01:28 <openstack> Meeting started Thu Apr 10 15:01:27 2014 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:31 <openstack> The meeting name has been set to 'manila'
15:01:44 <bswartz> hello folks
15:01:50 <yportnova__> hi
15:01:56 <rraja> hi
15:01:58 <xyang1> hi
15:01:58 <vponomaryov> hi
15:02:03 <shamail-web> hello
15:02:09 <Guest51361> hi
15:02:10 <bswartz> vponomaryov has added a few things to the agenda today
15:02:15 <bswartz> #link https://wiki.openstack.org/wiki/ManilaMeetings
15:02:21 <bswartz> let's start with those
15:02:27 <bswartz> #topic open items
15:02:54 <vponomaryov> from agenda: 1) Manila's entities do not require setting of name before creation. Should it be changed to required?
15:04:05 <bswartz> vponomaryov: where else in openstack are names required?
15:04:22 <vponomaryov> instances, network entities
15:04:35 <bswartz> is that new?
15:04:45 <bswartz> I always created unnamed instances before
15:05:19 <yportnova__> bswartz: it is not new
15:05:19 <vponomaryov> nova requires name
15:05:23 <bswartz> hmm
15:05:27 <vponomaryov> for booting instance
15:05:51 <bswartz> maybe I just used a default name and didn't think about it
15:06:09 <bswartz> so you're proposing requiring names for share-networks and shares?
15:06:21 <bswartz> what do you think the benefit of that would be
15:06:40 <vponomaryov> we mention it, because if do not set name we have empty string and horizon will show it
15:06:47 <vponomaryov> in table of entities
15:07:25 <bswartz> cinder doesn't require a name
15:07:25 <vponomaryov> for example, for share-network
15:07:51 <vponomaryov> we can leave all values empty and will have all empty strings in table
15:08:05 <bswartz> I could go either way on this
15:08:16 <bswartz> on the one hand, making the change now will be the least disruptive
15:08:26 <bswartz> however, it seems like a needless restriction
15:08:31 <bswartz> anyone else have an opinion
15:08:32 <bswartz> ?
15:10:03 <vponomaryov> We should just decide with it, I am ok lealing it as is
15:10:11 <xyang1> since cinder doesn't require it, I don't think we should add this requirement
15:10:21 <vponomaryov> /s/lealing/leaving
15:10:26 <bswartz> what does cinder show in horizon for volumes w/ no names?
15:10:49 <xyang1> I think name will be empty if you don't specify
15:11:15 <yportnova__> bswartz: ids
15:11:16 <vponomaryov> bswartz: it sets id in name column
15:11:26 <bswartz> yeah that's what I figured
15:11:36 <bswartz> okay let's leave it
15:11:53 <bswartz> #agreed names not required for shares and share-networks
15:11:58 <bswartz> next issue
15:12:16 <vponomaryov> open item 2) Manila's share-network can be created with any value of neutron-net-id and neutron-subnet-id. Should it be so, or only valid id's of neutron entities allowed?
15:13:10 <rraja> vponomaryov: what do you mean by 'valid' ids?
15:13:18 <vponomaryov> that exist
15:13:24 <rraja> ok
15:13:42 <bswartz> okay so first let's make sure everyone agrees
15:13:46 <vponomaryov> with proper relation net-subnet
15:13:59 <bswartz> the goal is to eventually make the network provider pluggable so we don't have a hard dependency on neutron
15:14:30 <bswartz> for now a dependency on neutron is okay because that's the only realistic alternative within openstack
15:14:53 <bswartz> any issue with that goal?
15:15:28 <vponomaryov> only displaying it in horizon
15:15:46 <vponomaryov> by default we use mapping name -ids
15:16:15 <vponomaryov> and what should be shown when there are empty/nonvalid ids
15:16:22 <bswartz> do we have a good way to handle mapping shares in a flat network environment?
15:16:52 <vponomaryov> I meant different mapping
15:17:12 <vponomaryov> id of entity to appropriate name if exists
15:17:15 <bswartz> I think the 2 imporant use cases today are: (1) network segmentation w/ neutron and (2) flat network
15:17:47 <bswartz> in the future we want to add (3) network segmentation with other tools
15:18:33 <bswartz> since (1) is harder that's where we've spent the effort so far
15:18:58 <bswartz> but we want to avoid making (2) harder
15:19:04 <bswartz> and (3) too, but that's further down the road
15:20:01 <bswartz> vponomaryov: it seems that we can tighten up the error checking on share network creation later
15:20:39 <bswartz> if a user submits something invalid it will fail at some point anyways
15:21:10 <rraja> bswartz: +1
15:21:20 <vponomaryov> bswartz: I am talking about period, before activation, when it is not validated yet
15:21:26 <bswartz> I don't want to spend time on error checking until we have a very good idea of what all values we want to accept
15:21:49 <bswartz> so vponomaryov, what kind of check would you propose?
15:22:09 <bswartz> just validate that the number maps to something real at creation time, by calling a rest api on neutron?
15:22:34 <vponomaryov> it is related to horizon
15:22:48 <vponomaryov> it gathers info and send requests to get names
15:23:08 <bswartz> so your concern is that an invalid ID will cause horizon to blow up?
15:23:16 <vponomaryov> in case of empty/invalid ids we need show something
15:24:07 <bswartz> can't we just default to "unknown" if horizon can't figure it out?
15:24:41 <vponomaryov> yes we can
15:24:50 <vponomaryov> also we can show its value
15:25:03 <vponomaryov> but need choose one
15:25:13 <vponomaryov> one variant of possible
15:25:24 <bswartz> I like unknown
15:25:48 <vponomaryov> ok
15:26:38 <bswartz> any other issues to discuss before we go on?
15:26:52 <vponomaryov> not from me
15:27:19 <bswartz> #topic dev status
15:27:31 <vponomaryov> Dev status:
15:27:39 <vponomaryov> Horizon
15:27:43 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/horizon-integration
15:27:43 <vponomaryov> code: #link https://github.com/NetApp/horizon/tree/manila
15:27:44 <vponomaryov> manual: #link https://wiki.openstack.org/wiki/Manila/docs/HOWTO_use_manila_with_horizon
15:27:44 <vponomaryov> status: beta available, work in progress
15:28:11 <vponomaryov> thats all
15:28:12 <bswartz> thanks vponomaryov
15:28:20 <rraja> We were able to create the service VM image that needs 64M RAM to boot up. The booted VM can work as a NFSv3/NFSv4/SMB server(tested with Manila generic driver framework) but not yet as a Ganesha server. Also the image has the NFS and CIFS client programs if one wants to use it as a guest image as well.
15:28:39 <rraja> people.redhat.com/chenk/cirros/cirros-generic-svm-934998f.qcow2
15:29:00 <bswartz> horizon has been the major focus of development in the last week -- with an eye towards atlanta
15:29:16 <bswartz> remember that we only really have 4 more weeks until the conference
15:29:40 <bswartz> rraja: that's great!
15:29:42 <vponomaryov> rraja: thanks, will try it
15:29:57 <bswartz> rraja: does that mean you found workarounds for the initrd stuff?
15:29:59 <rraja> bswartz: thanks!
15:30:12 <rraja> source tree: https://github.com/csabahenk/cirros/tree/manila-service-generic
15:30:51 <rraja> bswartz: yes! csaba did. :)
15:31:07 <rraja> s/csaba/chenk
15:31:42 <bswartz> thanks
15:32:11 <bswartz> rraja: what additional work do you have planned then?
15:32:19 <bswartz> still going to spend time trying to get ganesha to work?
15:32:31 <bswartz> does ganesha work if you use a larger/standard image?
15:33:07 <rraja> bswartz: we have not trying installing ganesha in the image. so i'm not sure.
15:33:52 <rraja> and now we plan to concentrate on working on our multi-tenant driver that would integrate with the generic driver framework.
15:34:01 <bswartz> rraja: oh okay
15:34:13 <bswartz> would that driver start out using plain nfs-kernel-server?
15:35:20 <rraja> no. it'd use nfs-ganesha. so first we need to get our single tenant driver working with NFS Ganesha, and right now it works with only gluster-nfs
15:35:32 <bswartz> okay
15:35:35 <bswartz> well I'm excited about that
15:35:51 <rraja> bswartz: thanks!
15:36:23 <bswartz> however that won't be done soon thought, right? certainly not in time for atlanta?
15:37:05 <rraja> yeah. my guess is that we can't, but hoping we will.
15:37:14 <bswartz> well that's what I wanted to talk about next
15:37:19 <bswartz> #topic atlanta
15:38:09 <bswartz> so it's time to start getting the plans for the presentation and demo sorted out
15:38:35 <bswartz> we've talked to several companies that would like to participate
15:38:45 <bswartz> but I'm missing contact names for some
15:38:48 <bswartz> is anyone from IBM here?
15:40:22 <bswartz> rraja, the name I have from Redhat is John Walker, does that sound right?
15:40:30 <rraja> yes
15:41:04 <bswartz> okay
15:41:19 <bswartz> I'll have to followup on IBM
15:41:31 <bswartz> the people coordinating the presentation should be in touch shortly
15:41:46 <bswartz> xyang1: does EMC have a driver in a demoable state?
15:42:00 <xyang1> EMC have two drivers
15:42:09 <xyang1> we are still working on horizon piece
15:42:21 <bswartz> xyang1: what horizon piece?
15:42:26 <xyang1> how long should we prepare the demo
15:42:31 <xyang1> I mean horizon integration
15:42:39 <xyang1> we need that right
15:43:09 <xyang1> mutitenancy support is another thing we are still working on
15:43:10 <bswartz> xyang1: the exact format is still TBD -- we obviously want to show off the horizon interface, but that could very well not be live
15:43:22 <xyang1> ok
15:43:23 <vponomaryov> xyang1: horizon talks to api, how development of driver can be related to horizon?
15:43:49 <xyang1> vponomaryov: I mean we need to setup with horizon to show that
15:44:13 <vponomaryov> xyang1: in that case you just need setup it at all
15:44:15 <xyang1> vponomaryov: I mean we need to follow your wiki steps
15:44:22 <xyang1> yes
15:44:40 <vponomaryov> xyang1: do you have problem with setup?
15:45:18 <xyang1> vponomaryov: I haven't tried yet.
15:45:22 <bswartz> xyang1: when do you anticipate your driver can go up on gerrit (in at least a WIP state)
15:45:47 <xyang1> bswartz: we are not there yet.  still need legal approval
15:46:08 <bswartz> xyang1: I know legal approval can be a slow thing, but are we talking days, weeks, or months?
15:46:09 <xyang1> bswartz: we are working with legal on that
15:46:32 <xyang1> bswartz: probably months:(
15:46:54 <bswartz> okay -- so anything we show in atlanta would be unreleased code
15:47:16 <xyang1> bswartz: ya, most likely
15:47:36 <vponomaryov> planned live demo?
15:48:17 <bswartz> vponomaryov: live demos have their drawbacks ;-)
15:48:23 <bswartz> we will see
15:48:38 <bswartz> I'd love to show something live, but we have to be realistic
15:48:53 <vponomaryov> =)
15:49:21 <bswartz> the main point I wanted to make is that we need to start firming up the presentation now, given the timeline for the conference
15:49:44 <bswartz> we're not going to plan this out the week before -- it needs to be solid in the next week or 2
15:49:54 <bswartz> okay enough on that
15:50:00 <bswartz> #topic open discussion
15:50:04 <bswartz> any other topics from anyone?
15:50:17 <yportnova__> bswartz: yes
15:50:24 <yportnova__> one question
15:50:27 <yportnova__> Do we need to have possibility to create two separate share-netwroks with the same pair neutron net/subnet?
15:50:43 <yportnova__> in one tenant
15:51:25 <bswartz> yportnova__: I believe yes -- if you want each to have different security
15:51:33 <bswartz> do you disagree?
15:51:42 <yportnova__> bswartz: agree
15:51:53 <yportnova__> just needed to clarify
15:52:05 <bswartz> okay
15:52:14 <bswartz> anything else?
15:52:53 <bswartz> okay thanks everyone
15:53:03 <bswartz> #endmeeting