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