13:00:02 #startmeeting nova api 13:00:03 Meeting started Wed Jul 12 13:00:02 2017 UTC and is due to finish in 60 minutes. The chair is alex_xu. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:06 The meeting name has been set to 'nova_api' 13:00:09 who is here today? 13:00:13 o/ 13:00:33 o/ 13:01:22 ok, let us start the meeting 13:01:40 #link https://review.openstack.org/467999 13:01:47 o/ 13:02:04 gmann_: thanks for the quota-class fix 13:02:33 #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/api-no-more-extensions-pike 13:02:44 alex_xu: we need client side support also for 2.50? 13:03:04 alex_xu: for quota fix microversiob 13:03:08 gmann_: ah, right, 13:03:34 ok, ll push tomorrow 13:03:53 tempest tests not needed as it is just api layer level changes only 13:03:54 gmann_: thanks 13:04:34 gmann_: ok 13:05:02 gmann_: so we need tempest tests when it is more complex functional change? 13:06:17 alex_xu: mainly for integration tests where more services involved or it is more complex involving multiple layer till hypervisor etc 13:06:34 gmann_: got it, thanks 13:06:38 for api and db layer changes we avoid 13:07:08 the functional test and unittest will cover that 13:07:16 yea 13:08:07 for the api-no-more-extension, I addressed one of -1 and rebase the patches 13:08:33 stephenfin: some of patches may need another round review, appreciate if you can help 13:08:50 and hope I can catch sdague to help on the review 13:08:59 alex_xu: Yup, I saw them this morning. They're all in my backlog for once I finish the doc-migration rework 13:09:08 stephenfin: thanks 13:09:09 (Would appreciate reviews on that series too :)) 13:09:29 alex_xu: np 13:10:01 ok, there is item from Matt 13:10:32 he sent an email this morning 13:10:35 #link http://lists.openstack.org/pipermail/openstack-dev/2017-July/119581.html 13:11:19 But I think I didn't describe clearly in the patch review. I agree with idempotent, I'm just ask about saving db call if there is nothing changed in real 13:11:49 only one of things I think that may not right. 13:12:47 When the user enabled a serivce, and specified a disabled_reason, the patch just ignore the disabled_reason sliently. I think we should return 400 explicitly 13:13:09 alex_xu: oh, is it 13:14:40 that confuses the user 13:14:54 alex_xu: yea, all those go through single update method 13:15:13 gmann_: yea 13:15:27 I had a look at that briefly. Ed's response was right for what Matt said, but your clarification alex_xu changes things a bit 13:16:39 cdent: ah, so 204 should return a empty body? 13:16:58 if the response is 204, then the body should be empty 13:17:09 but I was meaning more about the desire for put to be idempotent 13:17:16 cdent: alex_xu yea 204 seems like different status on same API depends on what state resource was 13:17:51 +1 for idempotent 13:18:07 but it should be single status code 13:19:33 * cdent looks at the review 13:19:33 is it worth to change that? 13:20:00 so what nothing in the request body, the patch return 400, it is worth to return 204 and empty body? 13:20:13 s/what nothing/what about/ 13:20:35 under what circumstances is 400 being returned? 13:21:08 cdent: a empty request body like '{}' 13:21:21 cdent: if enable or disable without host and binary 13:21:38 #link https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/services.py#L28 13:21:44 that sounds like a bad request, so 400 is correct? 13:21:48 current schema ^^ 13:22:02 yeah, if there is a schema violation, 400 13:22:10 how would 204 come into that? 13:22:54 yea, that should be 400, I just think idempotent as nothing change, that is different case 13:26:33 another question, if disabled_reason specified in the request, but without specified the status as enabled or disabled, should we return 400? or just think it is ok, because it just update an attribute of the resource? 13:27:45 alex_xu: 'without specified the status as enabled or disabled' but it has to be either as action 13:28:25 alex_xu: got it, you mean other than disable-log-reason 13:28:34 gmann_: the new version proposal the API just like a update of resource https://review.openstack.org/#/c/464280/21/nova/api/openstack/compute/schemas/services.py 13:28:44 yea 13:31:01 cdent: do you have any opinion? 13:32:24 I would think that disabled_reason without 'status' is a 400? 13:33:17 If we just think about PUT is action update the attributes of the resource 13:33:40 the code will be easy. But probably enable some useless usecase. 13:35:20 (side note: all the bp/api-no-more-extensions-pike patches are reviewed now, alex_xu) 13:35:39 so I think we agree that we should return 204 with empty body, right? 13:35:51 stephenfin: thanks 13:36:48 gmann_: ok, I saw your email reply :) 13:37:15 I think we can just move the discussion to the maillist 13:37:32 alex_xu: i replied not to return 204. i mean same status code with same response as on first request 13:38:27 sorry I need to depart early 13:38:29 * cdent waves 13:38:30 alex_xu: otherwise as user i have to take care of multiple status code on API depends on first or further call 13:39:12 alex_xu: yea we can move further and discuss on ML 13:39:28 gmann_: but I guess 204 is signal about there is nothing change 13:39:46 gmann_: yea, let us move to the ML 13:40:15 so we can close the meeting now? that all I have 13:41:19 ok, let us close the meeting 13:41:23 thanks all! 13:41:27 #endmeeting