15:05:12 #startmeeting manila 15:05:13 Meeting started Thu Mar 3 15:05:12 2016 UTC and is due to finish in 60 minutes. The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:05:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:05:17 hey :) 15:05:17 The meeting name has been set to 'manila' 15:05:20 hi 15:05:21 hi 15:05:22 hello 15:05:23 much better 15:05:25 hi 15:05:26 ha 15:05:35 hi 15:05:36 Jokes on the Freezer guys, they get our random banter at the end of their minutes :D 15:05:41 Joke's* 15:05:45 Hey all 15:06:01 alright there is only 1 priority today 15:06:14 we have to tag the milestone and some stuff isn't merged yet 15:06:20 hi 15:06:34 so I'm going to cover the items I know about any if I miss anything please chime in 15:06:42 #topic migration code 15:06:58 #link https://review.openstack.org/250518 15:07:02 #link https://review.openstack.org/#/c/250515/ 15:07:09 #link https://review.openstack.org/#/c/250515/ 15:07:15 okay client is rebased 15:07:19 server is waiting for recheck 15:07:31 I think this one is fine except for recheck hell 15:08:02 #topic tegile driver 15:08:13 #link https://review.openstack.org/#/c/278169/ 15:08:28 I believe this one is fine, just waiting for +1 from tegile CI, since it failed the last run 15:08:37 the CI has been stable for weeks though 15:09:03 #topic ceph driver 15:09:19 #link https://review.openstack.org/#/c/274952/ 15:09:29 there's problems with the client patch 15:09:42 who is fixing this? 15:09:48 rraga? 15:09:50 rraja? 15:09:54 bswartz: i'm working on it. 15:10:20 rraja: i'm just consulting with cFouts who did the wraps implementation in manilaclient 15:10:36 rraja: this won't take more than a few minutes right? 15:10:38 rraja: we'll help you resolve that issue... sorry for the delay 15:10:48 oh, is there more than I realize? 15:10:50 bswartz: i've been closely working with the help of gouthamr and ganso to get to the right approach 15:11:03 how far away are we from having a successful patch? 15:11:09 bswartz: there were some issues that need to be sorted out. 15:11:46 rraja: is there any functional issue to sort out? 15:11:54 rraja: I'm looking for a number -- an amount of time 15:12:12 I'm hoping to push tags within a couple of hours 15:12:32 rraja ganso: Valeriy would suggest adding a functional test if he were here i guess.. but we can defer that to later. 15:12:54 gouthamr, rraja what is currently issue exactly? 15:12:56 are there no functional tests or just insufficient tests? 15:13:21 correct me if I'm wrong, but the ceph driver won't work without this client patch 15:13:23 ganso: i was hoping we can get away without the wraps decorator.. but i was wrong about that. 15:13:23 bswartz: ok. i've not written any functional tests, i've just unit tests. and 15:13:57 rraja: please do any additional functional tests in another patch 15:14:03 bswartz: any functional tests will be just to test whether the access rule request can be made.. it won't apply the rule with the generic driver.. 15:14:14 bswartz: as far as I know it works, the client patch is mostly adding an access type validation that is standard in the manilaclient 15:14:21 we need to get this one done 15:14:24 bswartz: so maybe we can make do with the unit test 15:15:16 rraja: I'm still waiting for a time estimate 15:15:35 will this be done within the hour, or should I look for it after lunch? later this evening? 15:16:03 bswartz: without the unit tests, and if gouthamr is clear with an answer for my question i can get it done soon. maybe even in an hour. 15:16:15 okay that's the right answer! 15:16:22 wait 15:16:27 you said without unit test? 15:16:35 bswartz: he has unit tests 15:16:37 I though there were unit tests and the funcitonal tests were missing 15:16:41 rraja: commented on your patch 15:17:17 bswartz: sorry! i need to rearrange unit tests. so give me a couple of hours to be on the safer side. so what time is lunch? it's 9 PM my time now 15:17:30 we don't have a couple of hours 15:18:03 bswartz: OK. give me an hour then. 15:18:03 2 hours tops 15:18:06 okay 15:18:08 thank you 15:18:18 #topic gluster heketi 15:18:44 There are 3 patches here, and CI hasn't been seen reporting ever 15:18:49 I'm pushing this one to newton 15:19:17 OK 15:19:42 #topic manila UI patch for share instances 15:19:47 #link https://review.openstack.org/#/c/260554/ 15:20:03 vponomaryov: you said you were going to look at this ^ 15:20:27 * bswartz wonders where vponomaryov is 15:21:16 okay so this is a tough one 15:21:25 it's been up for a long time, but received no attention 15:21:32 I'm uncomfortable merging it this late 15:21:43 I'm inclined to push to newton 15:21:43 bswartz: +1 I'm not sure why this is critical. 15:22:23 cknight: I think it was supposed to lay groundwork for share replication UI, but that also hasn't been working on in mitaka 15:22:33 other than u_glide's prototype last year 15:23:03 I think we'll have to look at UI updates for replication in Newton 15:23:14 and this patch can slip to newton too 15:23:29 so I'll be tagging manila-ui immediately after the meeting 15:24:15 #topic cursed patch fixing help outputs in client 15:24:20 #link https://review.openstack.org/#/c/267383/ 15:24:36 I see 9 rechecks here 15:24:40 bswartz: Definitely cursed. 15:24:49 am I missing something? 15:25:00 bswartz: i've found that recheck with some cheesy encouragement message to jenkins will push patches through 15:25:11 lol 15:25:30 are we sure it doesn't need rebase or something else to get it through? 15:26:26 bswartz: the logs seem to suggest those failures are the usual suspects with the generic driver 15:26:27 probably needs a rebase 15:26:43 that patch isn't essential, but I'd like to see it go in 15:27:10 so if someone has some jenkins-fairy-dust, please sprinkle it on that patch 15:27:23 #topic admin-only CLI help 15:27:30 #link https://review.openstack.org/287436 15:27:42 this one is controversial 15:27:51 o 15:27:53 xyang markstur and I approved it 15:28:08 i'll chime in here 15:28:09 gouthamr vponomaryov cknight ganso dislike it 15:28:15 I dont think we have admin apis 15:28:18 that doesnt make sense 15:28:32 we have some policies that default to admin only 15:28:32 ameade: +1 15:28:41 ameade: I think the argument has been made already 15:28:52 we talk about admin api in our docs as well 15:29:00 the question is whether xyang or markstur want to change their opinions 15:29:07 why is this help text such a big issue 15:29:10 I initially disliked it, but didn't block it. 15:29:12 glance tried to solve this way back by having the client grab wadls that are generated based on what actions the requested user can perform 15:29:24 that was complicated to say the least 15:29:31 would we really be helping users? 15:29:34 and slow since the client had to grab the wadl 15:29:41 ameade: +1 That sounds like a lot of work for little gain. 15:29:47 we'd be confusing them even more. 15:29:54 yes nobody is proposing figuring out which APIs are admin only at runtime for help purposes 15:30:29 private clouds often open up more apis to users 15:30:36 bswartz: i'm with you on saying that horizon would be a nice place to do some admin validation.. but CLI shouldn't be.. 15:30:41 and big clouds may do more complex rbac 15:30:41 my opinion is that the vast majority of installation don't modify policy.json, and the ones that do are the least likely to need client help text 15:31:14 so having slightly inaccurate help text is harmless, and the benefit is that inexperienced users are less confused 15:31:15 bswartz: i don't agree ... it is probably modified extensively by providers.. 15:31:24 I know I'm in the minority here 15:31:36 bswartz +1 15:31:49 bswartz: +1 15:32:03 its easy for an administrator to modify policy.json 15:32:11 would it be easy for them to change the python files? 15:32:12 i'm not sure what my opinion is here but i'm leaning towards gouthams suggestion 15:32:32 just to avoid lying to the user 15:32:53 we've solved this problem with the server. my vote's for using that solution as elegantly as we present it :) 15:33:06 ameade: +1, we should avoid lying and confusing our users 15:33:06 it would be nice if there was a way to solve the confused newbie user problem in a 100% accurate way 15:33:17 This stuff is complicated enough as is 15:33:39 We will be lying to only those users who are modifying the policy.json 15:33:50 I still believe the way we've implemented is helpful in the vast majority of cases 15:33:58 Yogi1: users generally have no access to that, i would assume 15:34:01 However for those who don't modify its useful 15:34:22 yes there are cases where it's wrong 15:34:30 i dont have my finger on the pulse of how often policy.json is tweaked 15:35:01 Well, we respond with a 403 and a Administrator privileges are required for this request; don't we? 15:35:02 one thing we've learned is that the vast majority of openstack deployments are private cloud, in an enterprise setting 15:35:14 most of our admin-only is that way by design, not by whim 15:35:23 gouthamr We respond with 403 only after using the CLI 15:35:24 the dream of "public" openstack clouds is dying quickly 15:35:27 but we intend policy.json to be changeable 15:35:44 bswartz: i do tend to agree with that 15:35:52 this tagging gives info about it even before you try the command 15:35:53 yes... imho CLI is to make requests, not to do everything that the server already does.. 15:35:53 So the hard-coded help is a bad "design". 15:36:27 perhaps this is a problem for later? 15:36:34 Whether it is better merged or reverted. I'm OK with PTL decision unless there are other votes. 15:36:37 with swagger for all projects coming in 15:36:41 and moving to openstackclient 15:36:46 ameade: yes I'd like to solve the problem later 15:36:47 but we can't go back and forth 15:36:49 there may soon be easier ways to solve this 15:36:56 but we have a patch to consider 15:37:10 bswartz: could we not try to help users now with this? 15:37:46 I still fail to see the great harm leaving it in, and I agree with markstur that the worst thing we can do is go back and forth multiple times 15:37:50 most people are using horizon i imagine, making this less of an issue 15:37:53 we should solve the problem in a better way, i agree.. but not this way 15:38:17 I propose we wait for the solution that makes us all happy, and make the change then 15:38:35 bswartz: +1 15:39:05 bswartz: but then we shouldn't stay with what is not agreeable 15:39:19 bswartz: I think this should be reverted and thought through 15:39:20 bswartz +1 15:39:49 at least 3 cores agreed it should go in 15:40:03 that was regrettable because clearly we should have discussed it more in the first place 15:40:13 i dont think we should spend anymore time on it, bswartz makes the call and we all gotta be happy with it for now 15:40:24 however it's in, and I don't want to take it out and add it back later 15:40:43 I'm going to -2 the current patch and wait for a better solution 15:40:46 cool, will abandon the change, thanks 15:40:55 gouthamr thanks 15:41:02 #topic open discussion 15:41:05 that's the end of my list 15:41:10 did I miss anything important 15:41:23 wanna thank folks for the DR reviews 15:41:24 bswartz: anything news on the triple o patch 15:41:33 any news* 15:41:48 there will be a few more tweaks in mitaka i think so more reviews appreciated :) 15:41:56 dustins: I expect you to be more informed on redhat matter than me 15:42:10 last I heard, Manila was out of RHEL OSP 8, and out of 9 too 15:42:17 Indeed, yes 15:42:24 Manila is targeted to go into RHEL OSP 10 15:42:35 Yup 15:42:53 therefore the patch is moot until newton 15:43:06 Makes sense to me! 15:43:11 Thanks, bswartz! 15:44:03 okay if there's nothing else let's get back to merging stuff 15:44:31 when the tegile guys wake up somebody please poke them about their CI not reporting on their own patch 15:44:49 #endmeeting