15:00:15 #startmeeting manila 15:00:16 Meeting started Thu Aug 27 15:00:15 2015 UTC and is due to finish in 60 minutes. The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:19 hi 15:00:21 The meeting name has been set to 'manila' 15:00:21 Hi 15:00:22 hi 15:00:25 Hi 15:00:25 hi 15:00:27 hi 15:00:28 hi 15:00:29 \o 15:00:31 #agenda https://wiki.openstack.org/wiki/Manila/Meetings 15:00:41 hi 15:01:06 #topic liberty-3 status 15:01:16 #link https://launchpad.net/manila/+milestone/liberty-3 15:01:30 stuff is merging! 15:01:42 hi 15:01:52 thanks to all the reviewers helping with reviews and the submitters for rebasing like crazy 15:02:14 we have a week left until feature freeze and a lot of things to merge still 15:02:37 I'll just remind everyone to follow the blueprint priorities when doing reviews 15:03:02 #topic Compression capability 15:03:14 #link https://review.openstack.org/#/c/214485/ 15:03:26 I find some vendor are also support compression capability, such as netapp, huawei, etc. 15:03:27 so I add the compression capabilitie in common capabilitiy doc. 15:03:27 link: https://review.openstack.org/#/c/214485/. 15:03:53 The main question is do we agree on these compression capabilitie is "common". 15:04:07 personally I think compression makes sense as a common capability, and the docs update looks fine to me 15:04:16 my -2 was just to keep it from merging before this meeting 15:04:23 It's a simple name "compression" and simple boolean value so there shouldn't be much argument about that 15:04:45 anyone have a different opinion? 15:05:08 is this proposal the same as what cinder has? 15:05:17 bswartz: There are different types of compression, but those can be handled in vendor-specific extra specs, no? 15:05:42 yeah I think "compression" is certainly a cross-vendor concept 15:05:56 cknight, Sure there might be vendor specific additions 15:06:04 bswartz: sure, but some can do inline compression, others do it as a background job 15:06:07 individual vendors may have special sauce compression methods which could be handled by vendor scoped extra specs 15:06:15 bswartz: ok 15:07:00 I think the essential fact about compression is that it depends on thin provisioning 15:07:14 just like dedupe 15:07:25 bswartz: Cinder has a common capability named compression as well 15:07:56 okay I don't know if this need any more discussion then 15:08:00 yes 15:08:03 all are welcome to review the patch 15:08:16 I've changed my -2 to a +2 15:08:26 Thanks 15:08:44 #topic Microversions bug 15:08:53 #link https://bugs.launchpad.net/manila/+bug/1488624 15:08:54 Launchpad bug 1488624 in Manila "Microversions do not protect new clients talking to old servers well enough" [Critical,Triaged] - Assigned to Clinton Knight (clintonk) 15:09:41 so when we implemented microversions we missed one essential element of the nova implementation 15:10:03 the base URL in nova changed from /v2/ to /v2.1/ 15:10:33 if we don't also change our base URL, then new clients supporting microversions that talk to old servers not supporting microversions will get wrong behavior 15:11:05 we need to decide if we want /v1.1/ or /v2/ to be the URL for the "first microversion" 15:11:40 if we choose /v2/ then we can simply go back and renumber all the versions which have been added to start at 2.0 15:12:11 Personally I think the microversions change could warrant a rename to /v2/ 15:12:18 and in the release notes we can explain that v2 is really the same as v1, but because we've added microversions we'll never need a v3 15:12:34 bswartz: +1 15:12:41 bswartz: +1 15:12:44 I like v2 more than v1.1 just because it's shorter and v1.1 looks silly as we add 1.2, 1.3, etc 15:12:51 agreed 15:13:24 bswartz: +1 15:13:35 anyone prefer 1.1 or something else? 15:14:01 if no one is opposed then we'll go ahead and fix this bug by introducing the v2 URL 15:14:23 bswartz: an alternative is to drop the version in the URL altogether, but that could confuse people 15:14:38 cknight: I think we need something 15:15:07 anything else I can think of is longer not shorter 15:15:24 bswartz: I can make the changes to the server, and cfouts is making the client changes. 15:15:35 bswartz: I don't understand the Keystone stuff, though. 15:15:40 okay I don't hear any disagreement 15:16:04 if you need someone for the Tempest changes, I could do that 15:16:14 #agreed microversions support will be under /v2 and versions will be renumbered from 1.1, 1.2, 1.3 to 2.0, 2.1, 2.2 15:16:27 #topic open discussion 15:16:42 that's the whole agenda 15:16:46 anyone have something else? 15:17:10 The cli documentation stuff... 15:17:22 Do you want that in the upstream guide? 15:17:23 dustins: I think someone is doing updates to tempest to support microversions 15:17:33 bswartz: sounds good! 15:17:42 dustins: yes in the upstream guide 15:17:59 bswartz: You got it, I'll make sure to put it up there 15:18:25 okay thanks all 15:18:35 I'm sure you all want to get back to review hell and rebase hell.... 15:18:42 i was wondering about networking ... in one of the presentations I saw it mentioned that manila needed a flat network. I was wondering if that is still the requirement or if that has changed 15:18:46 review all the things! 15:18:58 so I'll give you back 41 minutes 15:19:10 manila-newbie: let's talk about it in the regular channel 15:19:15 okay thanks 15:19:16 #endmeeting