15:01:55 <bswartz> #startmeeting manila
15:01:56 <openstack> Meeting started Thu Feb 13 15:01:55 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:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:00 <openstack> The meeting name has been set to 'manila'
15:02:12 <aostapenko> hello everyone :)
15:02:13 <bswartz> good morning / good evening everyone
15:02:19 <xyang2> hi
15:02:24 <scottda> hi all
15:02:27 <achirko> hello
15:02:39 <bswartz> #link https://wiki.openstack.org/wiki/ManilaMeetings
15:02:42 <vponomaryov> hi
15:02:45 <csaba> hello
15:02:47 <rraja> hi
15:02:54 <vbellur> hi
15:03:02 <bill_az_> Hi everyone
15:03:10 <bswartz> #topic incubation
15:03:26 <bswartz> So we've been talking to the TC again about incubation
15:03:44 <bswartz> the official requirements are ever-changing, but here is the current list:
15:03:45 <bswartz> #link http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements
15:04:29 <bswartz> the main things that affect us here are:
15:04:30 <bswartz> ** Reviews should follow the same criteria as OpenStack projects (2 +2s before +A)
15:04:53 <bswartz> ** Project must have a diverse core reviewers team (more than 4 people)
15:05:04 <ndn9797> Hi all..
15:05:17 <bswartz> err
15:05:22 <bswartz> there's another one I can't find
15:05:41 <vponomaryov> ** Project APIs should be reasonably stable
15:05:54 <bswartz> But clearly the intention from the TC is that we need to be a large team with multiple contributing entities
15:06:54 <vbellur> bswartz: do we have a ballpark for the definition of large?
15:07:01 <bswartz> interestingly, the requirement that the code should be production-ready seems to have disappeared
15:07:23 <bswartz> vbellur: ** Project must have a diverse core reviewers team (more than 4 people)
15:08:07 <vbellur> bswartz: ok
15:08:15 <bswartz> and while it doesn't say so specifically, I think it's expected that those people don't all work for the same organization
15:09:15 <bswartz> so those of you who are making large contributions but are not in the core team I'm looking to grow the core team
15:09:41 <bswartz> reviews are also greatly appreciated -- especially because my time for core reviews is unfortunately limitted
15:09:49 <bswartz> s/core/code/
15:10:06 <bswartz> so enough on that, read the doc if you're interested
15:10:13 <bswartz> #topic Atlanta Summit
15:10:25 <bswartz> So I know that Atlanta is still a long ways off
15:10:51 <bswartz> however, it's looking like NetApp will be able to sponsor some conference sessions specifically for Manila
15:11:08 <vbellur> bswartz: that sounds great
15:11:30 <bswartz> We would like to be able to show off some demos of Manila doing cool things
15:12:04 <bswartz> so between now and then I've asked the dev team to start working on stuff like Horizon plugins in addition to core manila stuff
15:12:10 <esker> Here's our checklist for incubation "to do's"
15:12:17 <esker> https://wiki.openstack.org/wiki/Manila/Graduation
15:12:47 <bswartz> esker: hey!
15:12:52 <bswartz> good morning
15:13:12 <esker> bswartz: good morning
15:13:34 <bswartz> There are probably some other features we could add which aren't strictly necessary but would demo nicely, such as volume_type support
15:13:49 <esker> share_type
15:13:50 <esker> ;-)
15:14:04 <bswartz> volume_type support is something we've always known we needed to add but a possible demo in atlanta ups the priority of that work
15:14:15 <bswartz> esker: I actually prefer volume_type over share_type for several reasons
15:14:40 <bswartz> but whatever it's called, it's functionality we need to add
15:15:05 <bswartz> I'm looking for other ideas for features we could add or fix up that would contribute to a more successful demo
15:15:38 <bswartz> and between now and Atlanta I'll be doing checkpoints against our progress towards that end
15:15:46 <xyang2> is this demo netapp only, or will it include other backends?
15:15:50 <bswartz> anything else on this before we move on?
15:16:08 <bill_az_> it would be good to show multi-backend if possible - backends for several vendors working together is a good openstack thing
15:16:08 <scottda> I don't see a blueprint for file-type of share-type. Is there one?
15:16:17 <esker> I think demonstrating multiple backends would be fantastic
15:16:25 <bswartz> xyang2: the more backends the better -- demonstrating multibackend support with multiple hardware vendors would be very compelling I think
15:16:44 <xyang2> that's true
15:17:05 <bswartz> at this time I think we can commit to showing off the generic backend and the netapp backend
15:17:18 <bswartz> we have some time to add others
15:17:24 <xyang2> or maybe you can show some recorded demo of other backends
15:17:45 <xyang2> are you going to do live demo
15:18:04 <bswartz> heh, live demos carry a certain amount of risk
15:18:13 <bswartz> I don't think we've decided on that yet
15:18:15 <xyang2> right
15:18:21 <vbellur> a failure in a live demo makes it look authentic :)
15:18:26 <bswartz> in principle we could do a live demo, but recorded would be the fallback plan
15:18:47 <bswartz> vbellur: hah!
15:19:24 <bswartz> okay next topic
15:19:27 <bswartz> #topic dev status
15:19:37 <esker> a failure in a live demo would be tolerated better in a design summit session... but we're proposing to do this in the conference format.  I'd prefer to avoid folks leaving w/ a negative impression (especially  since it'll like be the first exposure for most to Manila).
15:20:02 <bswartz> vponomaryov: do you have status for us this week?
15:20:08 <vponomaryov> yes, sure
15:20:15 <vponomaryov> Dev status:
15:20:21 <vponomaryov> 1) Activation/deactivation api: https://blueprints.launchpad.net/manila/+spec/share-network-activation-api
15:20:29 <vponomaryov> Gerrit:
15:20:29 <vponomaryov> (server) https://review.openstack.org/#/c/71936/
15:20:29 <vponomaryov> (client) https://review.openstack.org/#/c/71497/
15:20:42 <vponomaryov> 2) Generic driver has been merged - https://review.openstack.org/#/c/67182/
15:20:53 <vponomaryov> 3) NetApp Cmode driver - https://review.openstack.org/#/c/59100/
15:20:53 <vponomaryov> Final stage of review.
15:21:03 <vponomaryov> 4) Horizon intagration estimation: it is upto 10 man-days.
15:21:16 <vponomaryov> 5) Volume types estimation: https://docs.google.com/document/d/1q1cz5TRBAXTev9hyswIGCy7lCPFE3slzmc9I-nwWrlw/edit?usp=sharing
15:21:33 <vponomaryov> now, OPEN ITEMS:
15:21:53 <vponomaryov> a) options "image" and "flavor" for share-network-activation api command
15:22:11 <vponomaryov> b) update devstack plugin for using generic driver?
15:22:11 <vponomaryov> dependencies: lightweight image, and reliable storage for it. Implementation of activation api for share-networks.
15:22:25 <vponomaryov> TODO:
15:22:35 <vponomaryov> - implement support of share-network activation/deactivation for generic and cmode driver after resolving open item for (1).
15:22:44 <vponomaryov> - horizon integration and testing
15:22:54 <vponomaryov> - volume types integration and testing
15:23:09 <vponomaryov> thats all for status
15:23:26 <bswartz> vponomaryov: wow
15:23:40 <bswartz> you're always well prepared vponomaryov
15:24:03 <vponomaryov> =)
15:24:04 <bswartz> okay so the activation API needs some discussing
15:24:16 <bswartz> I was reviewing it and I saw some stuff I didn't like
15:24:57 <vponomaryov> so, activation api is considered as admin-api only
15:25:27 <vponomaryov> there are default values for image and flavor for service VM
15:25:31 <bswartz> vponomaryov: why wouldn't we want tenants to be able to call it?
15:25:55 <vponomaryov> hm, we need clarify one thing
15:26:05 <vponomaryov> we have tenant admins
15:26:15 <vponomaryov> and we have cluster admin
15:26:23 <bswartz> isn't the point of the API so that tenants can error check the values they passed in for share-network-create?
15:27:11 <vponomaryov> no, share-network-create doesn't have check
15:27:18 <vponomaryov> it is another api command
15:27:40 <bswartz> I don't see any scenario where it's safe to allow tenants to start up a VM in the service network that's running a tenant-created glance image
15:28:14 <bswartz> vponomaryov: right, it's separate, but the reason we're adding it is so that they can call the second API to force the vserver to get created right away
15:28:49 <vponomaryov> yes, create VM, it is needed for Generic driver
15:29:15 <bswartz> I think tenant should be allowed to force the VM to be created, but they should not be allowed to control the glance image or nova flavor under any circumstance
15:30:25 <vponomaryov> if it is admin of tenant, why we should restrict to set custom image or flavor
15:31:00 <bswartz> the flavor because the VM will be outside their quota and we don't want to allow tenants to abuse that
15:31:45 <bswartz> the glance image because the VM will have routes to the backend network and therefore represents a security risk if mailcious software is installed in the glance image
15:32:18 <bswartz> we have to assume that the tenant/user of manila may be evil and want to try to takeover the openstack cluster
15:33:13 <vponomaryov> Ok, I see your point
15:34:23 <bswartz> note that there's nothing to prevent a user today from creating a glance image with nfsd/samba and runninging it themselves if they want to self-serve file access on top of a cinder provided-volume
15:34:41 <bswartz> they just won't be able to do that through manila
15:35:13 <bswartz> also -- it's important that backend-specific details of the generic driver do no bleed through to the tenant-facing API
15:35:31 <bswartz> because the tenant should be unaware of which backend they are talking to
15:36:03 <vponomaryov> there is no problem with it, while it is optional
15:36:24 <bswartz> those parameters would need to be admin-only in order to be safe
15:36:39 <bswartz> but I don't see the point of admin-only parameters which overlap with values in cinder.conf
15:36:47 <bswartz> I'd like the APIs themselves to be tenant-accessible
15:36:55 <bswartz> with no optional parameters
15:37:07 <bswartz> the use case is:
15:37:11 <bswartz> 1) create share network
15:37:18 <bswartz> 2) activate share network (using new API)
15:37:30 <bswartz> 3) find out if there are any errors with the config
15:37:33 <bswartz> 4) create shares
15:38:03 <bswartz> actually we could add a flag to create share network which optionally activates it too
15:38:19 <bswartz> but it's important to allow creating a share network and not activiating it
15:38:24 <bswartz> (at least I think it is)
15:39:02 <bswartz> enough on that
15:39:22 <csaba> bswartz: let me talk on service vm image project
15:39:22 <bswartz> Congrats to us for the generic driver going upstream!
15:39:36 <bswartz> csaba: just a moment
15:39:42 <csaba> sorryh
15:40:16 <bswartz> I'm still reviewing the NetApp driver -- anyone who wants to help please do today
15:40:44 <bswartz> vponomaryov mentioned the 2 new items we're looking at after the drivers are in
15:41:09 <bswartz> vponomaryov: did you want to talk about a lightweight image?
15:41:36 <vponomaryov> bswartz: csaba wanted to say about it
15:41:46 <bswartz> oh I get it
15:41:49 <csaba> s/vponomaryov/csaba/ :)
15:41:55 <bswartz> I didn't get the relation
15:41:58 <bswartz> lol
15:42:06 <bswartz> #topic lightweight service VM image
15:42:08 <csaba> yep
15:42:12 <bswartz> csaba go ahead
15:42:20 <csaba> so took cirros, lp:cirros
15:42:32 <csaba> which is a fine project but was a bit bit-rotten
15:43:00 <csaba> converted to git with buildroot as submodule
15:43:26 <csaba> as cirros is just a buildroot customization/wrapper project
15:43:47 <csaba> and added all stuff that we need / can make use of for the service vm
15:43:56 <csaba> #link https://github.com/csabahenk/cirros
15:44:05 <csaba> #link https://github.com/csabahenk/cirros/commits/manila-service-generic
15:44:27 <csaba> so  manila-service-generic is the branch you should build from
15:44:49 <bswartz> csaba: this is awesome
15:44:58 <csaba> we need community testing as we don't have yet a deployment with generic driver
15:45:09 <aostapenko> csaba: thanks
15:45:22 <vponomaryov> csaba: sounds great
15:45:23 <csaba> will build and publish images soon
15:45:40 <csaba> but in the meantime you can try to build yours
15:46:05 <csaba> of course any comment / contribution is welcome :)
15:47:15 <bswartz> so I'm not in favor of mandating a standard image -- I would rather document the requirements for the image and allow deployers to make their own -- but providing a reference image will be HUGELY helpful
15:47:30 <bswartz> I bet that 90%+ of admins will probably stick with the reference image
15:47:41 <bswartz> the question is how to distribute and promote the reference imge
15:47:42 <bswartz> image
15:48:00 <bswartz> because we're basically talking about another project
15:48:23 <bswartz> csaba: what are the chances of your changes going back upstream to cirros?
15:48:54 <csaba> bswartz: well its a further customization for specific purposes
15:49:21 <csaba> cirros' original ambition is to be a demo image
15:49:26 <csaba> a toy not a tool
15:49:36 <bswartz> yeah I get that
15:49:49 <vponomaryov> I whould like to have that toy for testing =)
15:49:54 <bswartz> but if we don't push the changes back into cirros the alternative is to maintain our own branch or else fork it
15:49:57 <csaba> so I didn't think of merging back
15:50:15 <csaba> cirros is not changing since a while
15:50:50 <bswartz> we would want the bits for the modified cirros image to be underthe control of the manila-core team if we're going to promote it as a reference image and use it for tempest testing, etc
15:51:02 <csaba> but yeah I can notify the original author what's his plans and optionon
15:51:30 <csaba> where would the ref images be hosted?
15:51:47 <bswartz> csaba: how is cirros hosted now?
15:52:11 <csaba> code is on launchpad
15:52:11 <esker> launchpad
15:52:18 <esker> https://launchpad.net/cirros/+download
15:52:24 <bswartz> no not the source -- the binary
15:52:29 <csaba> images are community contributions I think\
15:52:46 <esker> look again... binaries are there
15:52:49 <bswartz> oh I see the releases are there too
15:52:59 <vponomaryov> Tempest has next: http://download.cirros-cloud.net/0.3.1/cirros-0.3.1-x86_64-uec.tar.gz
15:53:22 <bswartz> well we should do something like this
15:53:42 <bswartz> perhaps a manila-reference-image project on LP
15:54:09 <bswartz> with the same governance as manila and python-manilaclient
15:54:31 <bswartz> uh oh the power is looking unstable here in RTP
15:54:42 <bswartz> my connection may drop, so let's wrap up the meeting
15:54:48 <bswartz> #topic open discussion
15:55:07 <esker> would prefer to just use the existing cirros project if the maintainers are agreeable
15:55:28 <bswartz> esker: it's just smoser who maintains it
15:55:36 <csaba> esker: the scope is different IMHO
15:55:57 <bswartz> esker: and it sounds like smoser is not particularly active anyways
15:56:09 <esker> Okay... the linux distro tree grows another branch
15:56:24 <bswartz> a very small branch, but yes
15:56:42 <bswartz> linux distros are a dime a dozen though
15:56:52 <bswartz> anyone else have something?
15:56:56 <bill_az_> regarding ganesha nfs - admin functions - has anyone played with that much yet? Things like adding / removing exports are a bit difficult today
15:57:14 <bswartz> bill_az_: that's good feedback -- I wasn't aware
15:57:35 <bill_az_> adding export requires editting ganesha conf and restarting server - there is dbus interface, but not fully baked yet
15:57:47 <bill_az_> I was wondering if anyone else has experimented with this?
15:57:53 <vbellur> bill_az_: I believe there is ongoing work to avoid restarting the server?
15:57:58 <bswartz> I would love to start using ganesha so we can shake out issues and start filing bugs with that project
15:58:12 <esker> how is ganesha nfs used in this context?  Are we not using in kernel NFS in the cirros branch?
15:58:16 <bill_az_> vbellur:  that's correct - planned for later this year is my understanding.
15:58:17 <bswartz> the sooner we find the bugs the sooner we can get them fixed and start using it heavily
15:58:39 <bswartz> esker: this is regarding the gateway-mediated multitenancy
15:58:49 <bswartz> stuff that's needed by GlusterFS, etc
15:58:53 <esker> ah, okay
15:58:54 <bill_az_> I've written some wrappers that I'm using with gpfs share driver -
15:58:58 <bswartz> the generic driver does not use ganesha currently
15:59:22 <bswartz> although we could decide to change that if ganehsa proves to be better
15:59:33 <alagalah> Morning
15:59:45 <bswartz> and that's about all we have time for
15:59:48 <bswartz> thanks everyone
15:59:56 <aostapenko> thanks, bye
15:59:57 <vponomaryov> thanks
16:00:04 <bswartz> #endmeeting