15:02:29 <bswartz> #startmeeting manila
15:02:29 <openstack> Meeting started Thu May 22 15:02:29 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:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:32 <openstack> The meeting name has been set to 'manila'
15:02:41 <bswartz> hello everyone
15:02:45 <vponomaryov> hi
15:02:47 <shamail> Hello
15:02:49 <xyang1> hi
15:02:50 <scottda> Hello
15:02:51 <mberlin> Hi guys.
15:02:52 <navneet> hi
15:03:09 <ameade> hey
15:03:15 <bswartz> #link https://wiki.openstack.org/wiki/Manila/Meetings
15:03:20 <bswartz> we have an agenda today
15:03:38 <bswartz> #topic Atlanta Summit
15:03:51 <bswartz> first I just wanted to recap the atlanta summit for those who couldn't make it
15:04:16 <bswartz> It was very awesome, and manila came up during presentations where I didn't even expect it
15:04:18 <yportnova> hi
15:04:26 <bswartz> lot of people were talking about the project, which is great
15:05:08 <bswartz> There was a session dedicated to Manila, where several vendors (including many here) presented
15:05:14 <bswartz> for anyone that missed it:
15:05:21 <bswartz> #link http://www.youtube.com/watch?v=fR-X7jbG5QM
15:05:42 <bswartz> ofc the lighting was really bad so you can't see the presenters too well
15:05:56 <scottda> Congratulations to the Core team. The demo was impressive and the room was packed full.
15:06:26 <bswartz> the room was indeed packed, we counted about 225 people in a room designed for 175
15:07:09 <xyang1> Wow!  I didn't realize there were so many people there.  This is great!  I hope TC got to watch the presentation
15:07:16 <bswartz> we also held a "design summit session" at a sports bar near the convention center because we weren't able to get on the official design summit track
15:07:43 <rraja> hi
15:07:51 <bswartz> I think it ended up working out better than an official session because we got to talk about what we needed to and we got lot of free food/beer
15:07:54 <navneet> bswartz: Do you want to mention the key takeaways for manilla during summit
15:08:22 <bswartz> navneet: I'm getting there but you're welcome to share your thoughts
15:08:40 <navneet> bswartz:sure
15:09:03 <bswartz> so there were a few new ideas that came up, and of course we still have a backlog of features we want to get done
15:09:15 <bswartz> I'm going to cover that in later topic
15:09:55 <bswartz> the main takeaway is that people are starting to find out about the project, and they like what they hearing -- there is definite interest in what we are building
15:10:28 <bswartz> now there is pressure to develop more faster, to expand the team, and to focus on stability and quality more than ever
15:10:55 <bswartz> We want to be incubated too, and I think that given the popularity we saw in Atlanta, that won't be a problem
15:11:31 <bswartz> however we still want to make it as easy as possible for the TC to say yes to our request so I'd like to see more contributions from non-code members
15:11:48 <bswartz> code reviews are always welcome
15:12:06 <shamail> bswartz: I think stability and Multi-vendor support for the project.  We still need a beta right?
15:12:10 <bswartz> let's get the drivers that are currently pending submission to actually be submitted
15:12:40 <xyang1> we are working on that
15:12:42 <bswartz> shamail: beta was during icehouse -- it should be ready to use now
15:13:05 <bswartz> in fact I know of several people who are setting it up and trying it out now
15:13:26 <shamail> bswartz: Awesome, great news.
15:13:27 <vponomaryov> it is actually beta
15:13:38 <bswartz> the API can't change anymore -- if further API changes (beyond what we've done already) are needed we should create v2
15:13:47 <shamail> I meant ppl trying it, sorry.
15:14:09 <xyang1> bswartz: do you have a customer who is going to run this?
15:14:24 <bswartz> xyang1: several
15:14:42 <xyang1> bswartz: cool!  TC will be happy to see that
15:15:16 <bswartz> I'm not sure which we can talk about -- we should go around and ask them if they'll make a public statement
15:15:50 <ameade> TC may be wary if we go in right away with a v2 API..just to keep that in mind
15:16:18 <bswartz> the last thing I'll say is that while we don't see much participation from the cinder core team in manila, I know that they're watching our progress and they were mostly impressed
15:16:52 <bswartz> yeah I don't expect we'll need a v2 API in the near future -- just making the point that it's time to lock down what we have
15:17:22 <shamail> bswartz: +1
15:17:29 <bswartz> last time we talked to the TC they made the point that API stability was a big deal and we didn't have that in november
15:17:57 <bswartz> okay anything else on Atlanta before I move on?
15:18:17 <bswartz> #topic dev status
15:18:22 <navneet> bswartz: any new ideas proposed
15:18:27 <navneet> ?
15:18:28 <bswartz> navneet: next topic
15:18:35 <navneet> ok :)
15:18:37 <vponomaryov> ok, Dev status:
15:18:42 <vponomaryov> Common:
15:18:47 <vponomaryov> share-networks activation API was removed. Implemented functionality of share servers, that use data from share-networks. Share-servers are created after first share creation request. Share-servers are deleted (can be disabled with config) after deletion of last share. No direct API for work with share-servers at the moment.
15:19:03 <vponomaryov> 1) share servers details infrastructure: #link https://review.openstack.org/#/c/94570/
15:19:11 <vponomaryov> 2) Multibackend tempest job:
15:19:18 <vponomaryov> bp: #link: https://blueprints.launchpad.net/manila/+spec/multibackend-installation-tempest-job
15:19:18 <vponomaryov> devstack #link: https://review.openstack.org/94588
15:19:18 <vponomaryov> tempest #link: https://review.openstack.org/94369
15:19:25 <vponomaryov> bug: #link https://bugs.launchpad.net/manila/+bug/1321340
15:19:26 <vponomaryov> fix: #link https://review.openstack.org/#/c/94655/
15:19:35 <vponomaryov> TODO:
15:19:45 <vponomaryov> 1) Update manilaclient with latest changes in manila
15:19:52 <vponomaryov> 2) Update horizon with latest manila changes (removing activation api)
15:20:02 <vponomaryov> 3) Refactor of service_instance module, then generic driver
15:20:11 <vponomaryov> 4) Add bash scripts that will be used in tempest jobs
15:20:17 <vponomaryov> 5) Add multibackend tempest job to openstack-infra/config project
15:20:36 <vponomaryov> that's the main for now
15:20:41 <bswartz> vponomaryov: ty!
15:20:54 <bswartz> vponomaryov: so we're still planning an admin-only API for share servers right?
15:21:05 <bswartz> just to list them
15:21:10 <vponomaryov> bswartz: we should disscuss it
15:21:13 <bswartz> okay
15:21:33 <bswartz> any questions about the above
15:22:15 <bswartz> what's to discuss regarding an API for listing share-servers?
15:22:27 <bswartz> I think it's something admins will want to see
15:22:43 <vponomaryov> what API should be at all?
15:22:50 <bswartz> and I think it's clear we can't have a tenant-facing API for that
15:22:54 <vponomaryov> read/update ...
15:23:15 <bswartz> I think we just need APIs for listing and querying details
15:23:37 <vponomaryov> hm, ok, sounds good
15:23:39 <bswartz> I can't think of anything we'd want to allow the admin to change -- the goal is that manila sets everything up so the admin doesn't need to change anything
15:23:58 <bswartz> ofc the admin can always to straight to the real backend and make changes if he chooses
15:24:12 <ameade> does manila have policies?... i think going forward apis should control access via policies instead of an explicit admin api
15:24:15 <bswartz> that's something we want to avoid for obvious reasons
15:24:31 <vponomaryov> ameade: of course
15:24:39 <bswartz> ameade: yes we do it the same way cinder does it, with policies
15:25:02 <ameade> kk cool, just making sure :)
15:25:18 <shamail> For generic driver, would SVMs be the share servers?  No real way to query them with a single command if this API doesn't exist.
15:25:22 <bswartz> alright
15:25:50 <bswartz> #agreed we'll add an admin API for listing/querying share servers, there will be no update/delete
15:26:06 <bswartz> shamail: that's exactly the point
15:26:25 <bswartz> we need to track the service VMs created by manila and the share-servers is how manila will do it
15:26:53 <bswartz> however the concept of a share-server is vendor neutral -- it should support abstractions used by all backends
15:27:02 <bswartz> in the netapp case a share-server is a vserver
15:27:24 <bswartz> and netapp marketing has started calling vservers SVMs just to make it more confusing
15:27:49 <shamail> bswartz: Yep.  I was only mentioning that since certain backends would have commands "out of band" to list servers while others won't.  Definitely agree with the admin API idea for level set.
15:28:35 <bswartz> the key here is that the backend gets to decide when/if to create new share servers, and manila needs to keep track of them so they can be managed
15:28:56 <bswartz> the scheduler also has to be aware of them so that, once created, they can be reused to minimize creation of extra ones
15:29:31 <bswartz> okay hopefully that's all clear
15:29:37 <bswartz> next topic
15:29:41 <bswartz> #topic blueprints
15:29:57 <bswartz> so there were some new ideas at the summit
15:30:02 <bswartz> and some old ideas got additional urgency
15:30:18 <bswartz> #link https://blueprints.launchpad.net/manila/+spec/non-vlan-multitenancy
15:30:24 <bswartz> #link https://blueprints.launchpad.net/manila/+spec/access-groups
15:30:30 <bswartz> #link https://blueprints.launchpad.net/manila/+spec/nova-integration
15:30:40 <bswartz> #link https://blueprints.launchpad.net/manila/+spec/mount-automation
15:31:10 <bswartz> those are the new ones I just added
15:31:51 <bswartz> and there are existing ones that are still important
15:32:16 <bswartz> in the next few weeks I'm going to be looking for people to work on all of these
15:32:36 <bswartz> does anyone want to volunteer right now?
15:32:46 <shamail> Any require design work?
15:32:53 <scottda> I cannot do all of these :)
15:32:56 <bswartz> yes they all do
15:32:57 <scottda> But I can do 1 or some
15:33:14 <bswartz> nearly all of these will require some discussion and agreement
15:33:19 <shamail> I can think about mount automation
15:33:21 <bswartz> but before we can do that some investigation is needed
15:33:41 <scottda> I can do non-vlan-multitenancy
15:33:56 <bswartz> scottda: wow that would be awesome
15:34:26 <bswartz> the trick to that one is that you'd need a backend that supported VLAN trunking to validate the design
15:35:03 <bswartz> I'll put assignees on these just for tracking
15:35:05 <scottda> I share a cube with a Neutron Dev, and sit amongst a whole team of Neutron folks, so I will have access to lots of networking help
15:35:18 <bswartz> I'll talk to individuals by PM after the meeting to make sure they're assigned right
15:35:43 <bswartz> and we can change it later on if we need to
15:36:14 <bswartz> but I'd like to use the upcoming meetings for design discussions on these and it would be good to have some experiments/prototypes to talk about
15:37:12 <bswartz> there will also be some more netapp people contributing directly soon and we'll see who can work on what
15:37:16 <bswartz> so expect an update on that next week
15:37:39 <bswartz> I think that covers the stuff I wanted to talk about today so I'll open the floor
15:37:46 <bswartz> #topic open discussion
15:38:41 <bswartz> there were some people questioning the name "volume_types"
15:38:47 <bswartz> any of them here to make their case?
15:39:20 <xyang1> should it be share_types instead?
15:39:34 <bswartz> that was a proposal I heard
15:40:02 <bswartz> if something thinks we should change it please put an agenda item up for next week and we'll discuss it
15:40:23 <xyang1> since we changed "volume" in other places to "share", it makes sense to change this one
15:41:18 <bswartz> xyang1: there's a counter argument though which is that while shares and volume are 2 different things, the term "volume_type" in cinder actually refers to the underlying storage more than the volume itself
15:41:34 <bswartz> perhaps cinder would have been better off with storage_type or something similarly generic
15:41:40 <shamail> I'm torn personally.
15:42:06 <bswartz> either way, manila is referring to the same concept of the underlying storage type, and because of the overlap/commonality I like to use the same term that cinder uses
15:42:09 <shamail> Exactly because of the reason you just stated.
15:42:14 <vponomaryov> bswartz: I like storage_type more then sahre_* or volume*
15:42:43 <bswartz> In particular, when you set a volume_type in manila, and the generic driver is used, it will create a cinder volume of the same volume_type to host the storage
15:42:45 <shamail> The BE volume has more impact on the characteristics of the "share" than the share itself.  It's consistency vs ambiguity.
15:42:49 <bswartz> in that case there really is a direct mapping
15:43:14 <bswartz> that's not to say it couldn't be handled correctly with share_types or somesuch
15:43:28 <bswartz> anyways this may come up again next week
15:43:40 <vponomaryov> bswartz: no, generic driver does not set volume_type to cinder
15:43:41 <bswartz> think about it and form an opinion
15:43:58 <vponomaryov> bswartz: volume_types in manila are used only for maila's backends
15:44:00 <bswartz> vponomaryov: I know that's not there yet, but we want to add it
15:44:18 <vponomaryov> ok
15:44:28 <bswartz> I don't see any problem with mapping the volume_type all the way through in the case of the generic driver
15:44:40 <bswartz> but I'm willing to be convinced otherwise
15:44:58 <vponomaryov> bswartz: we can have two generic drivers
15:45:12 <vponomaryov> and manila's volume_types will link to them
15:45:24 <vponomaryov> it is totally two different volume_types
15:46:06 <bswartz> okay well I don't expect to decide this today
15:46:15 <bswartz> anything else?
15:46:17 <xyang1> vponomaryov: you mean one generic driver in code, but run two instances of generic drivers?
15:46:25 <vponomaryov> yes
15:46:42 <bswartz> all the netapp people are quiet because a meeting started 16 minutes ago and I'm late to it....
15:46:50 <shamail> :)
15:47:10 <shamail> I gotta run too.  Have a great day everyone!
15:47:17 <bswartz> okay thanks everyone
15:47:26 <yportnova> thank you
15:47:27 <vponomaryov> thanks
15:47:29 <bswartz> scottda, shamail: I'm going to PM you in a moment
15:47:36 <shamail> Ok
15:47:38 <rraja> thanks
15:47:40 <scottda> bswartz: ok
15:47:44 <bswartz> #endmeeting