15:01:11 <bswartz> #startmeeting manila
15:01:13 <openstack> Meeting started Thu Sep 12 15:01:11 2013 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:16 <openstack> The meeting name has been set to 'manila'
15:01:23 <vikiland> hi Manila team
15:01:28 <bswartz> hello everyone
15:01:33 <vbellur> hello all
15:01:33 <yportnova_> Hi
15:01:35 <vbelokon> hi!
15:01:37 <vponomaryov> hi
15:01:39 <rushiagr> hi! new entry here :)
15:01:39 <xyang> hi
15:01:48 <bswartz> Sorry I'm just coming from another meeting, and I didn't prepare an agenda
15:01:59 <bswartz> hello rushiagr!
15:02:09 <vbellur> tkatarki_: hello
15:02:16 <rushiagr> hi bswartz!
15:02:27 <vbellur> rushiagr: hello there
15:02:31 <vbelokon> bswartz: we can discuss current status, then plans and current blueprints
15:02:57 <rushiagr> vbellur: o/
15:03:01 <bswartz> for those of you who don't know, rushiagr is a former netapp employee who was deeply involved with manila development when it was still being implemented as an extension to cinder
15:03:15 <vbellur> bswartz: should we discuss incubation plans or is it early?
15:03:37 <bswartz> rushiagr are you going to continue being involved with this project in your new job?
15:04:17 <bswartz> vbelekon: yes that's what I'd like to do
15:04:20 <bswartz> #topic status
15:04:20 <rushiagr> bswartz: I am entering into OpenStack world.. not sure if I will dedicate most of my time to Manila, but I would like to contribute atleast a little
15:04:48 <bswartz> okay well your participation is welcome rushi
15:04:58 <rushiagr> bswartz: thanks
15:05:05 <vbelokon> bswartz: ok, I will make short update
15:05:12 <bswartz> #link https://wiki.openstack.org/wiki/ManilaMeetings
15:06:08 <vbelokon> DevStack for Manila was implemented [https://github.com/bswartz/devstack]
15:06:16 <vbelokon> - Reworking of Cinder to Manila was implemented [https://github.com/bswartz/manila] "cinder-to-manila" branch
15:06:26 <vbelokon> - Tempest tests is in-progress [https://github.com/bswartz/tempest/tree/manila]
15:06:47 <vbelokon> Currently Manila has following functionalities:
15:06:50 <vbelokon> - Supporting of shares
15:06:53 <vbelokon> - Supporting of snapshots for shares
15:06:55 <vbelokon> - Quotas for users for shares
15:06:56 <vbelokon> - Limits supporting (rate, absolute)
15:07:28 <vponomaryov> and access list to shares too
15:08:26 <vbelokon> So, out plan for next week is testing and testing
15:08:31 <vbelokon> Perform integration tests, bug fixing
15:08:33 <vbelokon> Analyse and enter blueprints with new features, improvements
15:08:35 * rushiagr is happy to see many new functionalities in Manila
15:08:44 <vbelokon> and then upload Manila code to StackForge
15:09:25 <bswartz> vbelokon: maybe it's just github acting up, but I can't see the cinder-to-manila branch
15:10:00 <vbelokon> let me check
15:10:14 <vponomaryov> https://github.com/bswartz/manila/tree/cinder-to-manila ?
15:10:19 <vbelokon> https://github.com/bswartz/manila/tree/cinder-to-manila
15:10:29 <bswartz> oh nevermind
15:10:34 <bswartz> it was a user error
15:10:36 <vbelokon> bswartz: do you have access to this link?
15:10:41 <bswartz> thanks
15:11:11 <bswartz> okay
15:11:30 <bswartz> vbelokon: do you have experience with creating projects in stackforge?
15:11:42 <bswartz> It's something I haven't looked into yet
15:12:01 <vbelokon> bswartz: unfortunately - no
15:12:12 <bswartz> that will be a major milestone once we're integrated w/ stackforge becuse then it will be much easier for the rest of the community to contribute
15:12:18 <bswartz> okay
15:12:26 <bswartz> #action bswartz look into creating stackforge projects
15:12:36 <vbelokon> I can investigate uploading process
15:12:51 <vbelokon> if anyboyd has expirience - please share it :)
15:12:54 <bswartz> esker/resker: you here?
15:13:09 <bswartz> oh he's travelling, nm
15:13:26 <bswartz> by Monday I'll get an answer on that
15:13:40 <davenoveck> #help
15:14:06 <vbelokon> bswartz: ok - good
15:14:12 <bswartz> is there anything we need to discuss regarding the removal of the blocks-specific features?
15:14:24 <vbellur> this might help for adding to stackforge: http://ci.openstack.org/stackforge.html
15:14:43 <bswartz> vbellur: ty
15:15:04 <vikiland> no - we've removed all unnecessary functionality
15:15:10 <vbelokon> vbellur: good instrucions
15:15:28 <bswartz> vikiland: were there any questionable items? any difficult judgement calls?
15:15:46 <vikiland> no.
15:15:47 <bswartz> vikiland: in particular I'm wondering if we might need to remove some additional small bits in the future
15:15:50 <bswartz> okay that's good news
15:15:57 <vikiland> we have great experiences team ;)
15:16:26 <bswartz> anything else before we move on to blueprints?
15:16:46 <bswartz> #topic blueprints
15:16:51 <yportnova_> Bswartz: current unit tests coverage is 70%
15:17:06 <yportnova_> Do we need to increase it?
15:17:36 <bswartz> yportnova_: that sounds like an okay number to me -- but I'd like to see statistics on other openstack projects for comparison
15:17:51 <vbellur> i have added a couple of basic blueprints, nothing very actionable atm.
15:18:10 <bswartz> #link https://blueprints.launchpad.net/manila
15:18:40 <bswartz> vbelokon: do I need to make updates to any existing BPs?
15:18:47 <vbelokon> bswartz: yes
15:19:22 <vbelokon> https://blueprints.launchpad.net/manila/+spec/remove-blocks - good progress - needs code-review
15:19:37 <vbelokon> https://blueprints.launchpad.net/manila/+spec/rename-cinder-to-manila - the same
15:20:05 <vbelokon> and discuss the importance of all other blueprints
15:20:11 <bswartz> hmm LP is claiming the work was done by me
15:20:25 <bswartz> oh well if I can't fix it I guess it's not important
15:20:55 <vbelokon> ok
15:21:08 <vikiland> https://blueprints.launchpad.net/manila/+spec/devstack-testing
15:21:14 <bswartz> I still have some BPs to add
15:21:50 <vikiland> I've updated requirements for apt systems as well as for rpm and rpm-suse
15:21:54 <vbelokon> vikiland: we need volunteer for this BP :)
15:22:23 <vikiland> during this week we well tested our devstack on ubuntu env
15:22:27 <bswartz> okay we need to add placeholder BPs for integrating out tempest and devstack code into those projects respectively
15:22:56 <bswartz> and we need Icehouse-targetted BPs in those projects to do the actual integration
15:23:13 <bswartz> #action bswartz create placeholder BPs for tempest/devstack upstream work
15:23:15 <vbelokon> agree
15:23:32 <yportnova_> Bswartz: one thing about gigabytes quota for  snapshot . We do not have size attribute of snapshots
15:24:13 <bswartz> yportnova_: that's a good point
15:24:24 <bswartz> yportnova_: snapshot space accounting is bad enough in cinder, it will be worse for us
15:24:28 <yportnova_> So we can not implement it until size is added
15:25:03 <bswartz> yportnova_: can you file a BP expaining the missing feature?
15:25:11 <yportnova_> Sure
15:25:19 <bswartz> yportnova_: I suspect we may need a way for the driver to support querying snapshot size
15:26:17 <bswartz> the REALLY conservative answer would be to assume that the snapshot consumes the same amount of space as the original share (for quota purposes), but that seems far too conservative
15:26:54 <bswartz> if there's a driver interface to expose the real space consumption then we can get closer to the truth
15:27:17 <rushiagr> bswartz: maybe thats a good approximation for the first implementation. We can optimize later.. Thoughts?
15:27:33 <bswartz> the danger here is that measuring quota space consumption start to get into issues of metering and billing, which can be sensitive
15:28:39 <yportnova_> Bswartz: we can set no_gbquota in config
15:28:45 <bswartz> if the backend supports space efficiency, the administrator should get some choice for how much of that efficiency he exposes to his customers and how much he hides for himself
15:29:07 <yportnova_> In case snapshot size really differs from share size
15:29:36 <bswartz> I'd like to create an interface that's better than assuming the worst case, but that's easy enough that every vendor can implement it
15:30:29 <bswartz> yportnova_: is the quota issue something you plan to work on in the coming week?
15:31:38 <yportnova_> Bswarrz: I can work on it
15:31:53 <vbelokon> actualy, we are planning to perfome testing. And this issue stay to future development
15:32:38 <bswartz> My proposal for reporting snapshot space would be to perhaps report the total size of all the data within the share snapshot, assuming no compression or dedupe, but to account for unused space (if you only use 1GB of a 10GB NFS share, for example)
15:33:17 <bswartz> that would make sense if an admin exposed that number to an end-user -- and it's also relatively easy to support in a vendor neutral way
15:33:35 <bswartz> vbelokon: I'd prefer that I think
15:33:48 <bswartz> let's punt on issues and features until we're integrated into stackforge
15:34:05 <bswartz> anything that's not necessary for stackforge can be pushed
15:34:19 <bswartz> okay so back to the current topic of blueprints
15:34:28 <bswartz> vbellur: anything you'd like to discuss right now?
15:35:22 <vbellur> bswartz: nothing much on blueprints right now
15:35:51 <bswartz> okay
15:36:09 <bswartz> by next week we'll review the blueprints that are posted, and possibly add some more
15:36:30 <bswartz> but the priorities are testing/stabilization and stackforge
15:36:37 <vikiland> bswartz : problem with snapshot's size  in calculation
15:36:39 <vbellur> okay
15:37:02 <bswartz> vikiland: ?
15:37:17 <vikiland> it's hard to calculate actually used size so implementation of this feature could take more then few hours
15:38:04 <bswartz> vikiland: perhaps snapshot size is something we can collect as metadata at the time the snapshot is taken
15:38:34 <bswartz> vikiland: it needs to be a number that we can quickly generate, and it needs to have a defined lower-bound so that drivers are not encouraged to lie
15:39:16 <vikiland> ok
15:39:32 <bswartz> vikiland: the "default " implement should probably be the extreme conservative case of reporting the share size
15:39:38 <bswartz> implementation*
15:40:15 <bswartz> #topic open discussion
15:40:33 <vbellur> bswartz: any plans on an incubation proposal?
15:40:44 <bswartz> vbellur: one step at a time!
15:41:04 <bswartz> we plan do to it, but there is nothing concrete beyond what we've already done and the plan to go into stackforge
15:41:32 <bswartz> being in LP, having these weekly meetings, going into stackforge, these are all critical steps
15:41:41 <vbellur> bswartz: agree
15:42:28 <bswartz> I want to be able to submit an official application before Hong Kong
15:42:37 <bswartz> I believe we're on track to do that
15:42:47 <vbellur> bswartz: yeah, I think so too.
15:42:55 <bswartz> Hong Kong is 7.5 week away for those who are keeping track
15:43:18 <hub_cap> where is the code currently?
15:43:32 <bswartz> hub_cap: it's all on github under my account
15:43:42 <bswartz> by next week it should be in stackorge
15:43:45 <hub_cap> fwiw, i went thru incubation just a few mo' ago. feel free to ask Qs
15:43:52 <hub_cap> good, cuz i just got a 404 goin to stackforge ;)
15:43:57 <bswartz> hub_cap: thanks for the offer!
15:44:16 <hub_cap> np!
15:44:30 <bswartz> okay anything else?
15:45:04 <bswartz> alright thanks everyone
15:45:12 <bswartz> #endmeeting