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