00:01:13 #startmeeting nova-api 00:01:14 Meeting started Fri Jun 27 00:01:13 2014 UTC and is due to finish in 60 minutes. The chair is cyeoh. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:01:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:01:18 The meeting name has been set to 'nova_api' 00:01:27 Hi - who do we have here today? 00:01:32 hi 00:01:42 hi 00:02:02 Hi 00:02:18 ok, lets get started then 00:02:28 #topic microversioning spec 00:02:39 so it looks like we're down to just one proposal now: 00:02:45 https://review.openstack.org/#/c/101648/ 00:02:58 which should hopefully mean we can get some sort of consensus soon. 00:03:26 cyeoh: good to hear that:-) 00:03:26 This is Sean's version, and seems to have a reasonable amount of support 00:03:45 personally I think its mostly ok - but please review it if you haven't already done so 00:04:14 did anyone want to talk about microversions? 00:04:30 yea, I'd lik to add each extension version to the spec. after that, it seems ok 00:04:37 for me. 00:04:57 so you want a version for each extensions as well as a global version? 00:05:28 yes, I think we need extension version also for representing experimental API 00:06:02 both global and extension would be good for me. 00:06:52 yep we certainly do at least need the experimental flag somewhere 00:06:52 now server-group API should be experimental because the api has been released in icehouse and not enough to be tested 00:07:17 cyeoh: agree 00:07:17 though from Sean's proposal it looks like you'll request experimental of everything, or none at all 00:08:09 need more discussion. 00:08:41 yesm maybe some comment on Sean's proposal. Might need to list some use-cases like server-groups for example to see better how it would work 00:08:43 looks like same for request experimental through an global version or extension version 00:09:42 yes, and it looks like we donot want to give support for different API version set. for example client request to V201 and V203 not V202 will not be supported. 00:10:05 I think global experimental version means new "backwards incompatible" API and all of APIs is experimental. 00:10:09 gmann: yes that certainly won't be supported 00:10:28 and i think thats why sean proposal does not contain the version for each extension. 00:10:49 but extension experimental version means "the other APIs are stable, but this API only is experimental on the same global version" 00:10:54 oomichi: I think the global experimental in the proposal would bring in - experimental version where there is an experimental version of the api, and stable where there is not 00:11:19 oomichi: yep, though that is not supported in Sean's current proposal. Would need a per-extension header 00:11:45 from user side, user needn't distinguish the version is extension or global... 00:12:14 alex_xu: yes, that seems good point. 00:13:06 I'd like to consider again Sean's proposal with some use cases 00:13:33 oomichi: yep I think that would help 00:14:05 anyone have anything else? 00:14:07 is it ok to concentrate Sean's proposal only for now? 00:14:26 I guess the proposal does not need to include Alternative now 00:14:28 oomichi: yep, definitely - my original was abandoned 00:14:37 so it's just Sean's proposal now 00:15:06 ok, -1 due to including "Alternative" to Sean's proposal ;-) 00:15:22 heh 00:15:41 good point~ 00:15:59 #topic v2.1 on v3 00:16:18 I don't think there's much here to say except we're blocked here until the microversions spec is settled :-( 00:17:02 cyeoh: yea, we need to wait for microversion spec now. 00:17:16 #topic tasks api 00:17:43 please have a look at https://review.openstack.org/#/c/86938/ 00:18:08 if you haven't already done so (though that spec is dependent on v2 on v3 and microversions getting approved too.... 00:18:29 #topic open discussion 00:18:49 Does anyone have anything they want to talk about? Urgent reviews etc? 00:19:08 cyeoh: do you have any concerns/comments about tasks api now? 00:19:26 oomichi: no, I'm pretty happy with it 00:19:35 cyeoh: great :-) 00:19:55 api policy feel very close https://review.openstack.org/#/c/92005/ 00:20:10 oomichi: it will be a big improvement for users 00:20:17 appreciate any review 00:20:32 cyeoh: yea, many people hope it 00:20:47 I want to +1 for task api too 00:20:57 alex_xu: I'll have a look at your spec today 00:21:02 cyeoh, thanks 00:21:33 alex_xu: this also is good for deployers, nice spec. 00:21:49 oomichi: its a very long overdue cleanup! 00:22:03 oomichi, thanks, there are some deployer complain that in summit also 00:22:09 alex_xu: when the developement, is a huge amout of patch necessary for the policy? 00:22:37 I thought of going through task spec since many days but today i will definitely :) 00:22:39 oomichi, what means patch for developement? 00:23:31 alex_xu: after the spec is approved, we start the development for the policy improvement. so I'd like to know the development size. 00:23:47 I don't think there's a huge amount of patches, but they are really quite tricky. Because when moving the policy checks around need to be very very careful about accidentally creating security bugs 00:24:03 so needs extremely careful checks on the review side as well 00:24:29 oomichi, if the deployer didn't modify the policy before, then he needn't doing anything 00:24:36 cyeoh, +1 00:24:58 cyeoh: thanks, I got it. and I feel review viewpoints will be the same between patches. 00:25:12 oomichi: yep 00:26:04 cyeoh: yea, many environments would be operated on default setting for avoiding security issues. 00:26:30 cyeoh: this spec is really nice for customing the policy :) 00:26:32 oomichi: yes have to ensure the default stays the same 00:27:34 for nova-network related extension, we only can do it after they port to v2.1/v3 00:27:51 alex_xu: yep 00:28:03 I should add note to specs 00:28:31 is there anything else for open discussion? 00:29:01 nothing from me, I enjoyed it:) 00:29:09 nothing from me too 00:29:18 Nothing here 00:29:25 cool - ok we'll end early then :-) Thanks everyone! 00:29:35 thanks all 00:29:36 thanks all 00:29:37 Thanks All. 00:29:44 #endmeeting