13:00:03 <alex_xu> #startmeeting nova api
13:00:04 <openstack> Meeting started Wed Oct 19 13:00:03 2016 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:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:07 <openstack> The meeting name has been set to 'nova_api'
13:00:12 <alex_xu> who is here today?
13:00:29 <edleafe> \o
13:00:33 <jichen> o/
13:00:34 <sdague> o/
13:00:44 * edleafe will have to run out to take his daughter to school in a bit
13:01:07 <alex_xu> wait one more minute for people join in
13:01:59 <alex_xu> ok, let us start the meeting
13:02:04 <alex_xu> #topic Action from previous meeting
13:02:15 <alex_xu> only one action
13:02:17 <alex_xu> alex_xu to write first draft of spec on parameter validation for next week
13:02:29 <alex_xu> #link https://review.openstack.org/388518
13:02:34 <alex_xu> ^ it is the spec
13:02:45 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:poc_query_params
13:03:03 <claudiub> o/
13:03:15 <alex_xu> ^ and the poc, it needs more works, but you can take a look at how it looks like basically
13:03:31 <johnthetubaguy> o/
13:04:11 <alex_xu> The idea is using JSON-schema and VersionObject
13:04:47 <johnthetubaguy> VersionObject?
13:04:53 <alex_xu> JSON-schema is used to validate the query parameters, then mapping into a object. In the API method, developer just need access the object insted of the webob request obj
13:05:31 <alex_xu> johnthetubaguy: yea... it is at https://review.openstack.org/#/c/388390/3/nova/api/openstack/compute/objects/servers.py@68
13:05:59 <alex_xu> I'm looking for something instead of the wild dict in the request object. But maybe it is over complex
13:06:44 <johnthetubaguy> The dict at the top I was expecting, the other bit, I am less sure about
13:07:04 <edleafe> So would there be a different object defined for each API method?
13:07:25 <alex_xu> edleafe: for each API which use query parameters
13:08:02 <edleafe> alex_xu: that seems a bit heavy-handed
13:08:07 <alex_xu> I'm try to get the code https://review.openstack.org/#/c/388391/3/nova/api/openstack/compute/servers.py@246 out of API method
13:08:15 <johnthetubaguy> all we need is *args, **kwargs -> json string I assumed?
13:09:45 <alex_xu> edleafe: yea, a little boring writing object after wrote a json-schema, I'm try to figure whether have enough benefit to introduce that object
13:09:49 <johnthetubaguy> and the decorator just takes the parameter schema
13:09:50 <alex_xu> johnthetubaguy: sorry, I didn't get you
13:10:06 <johnthetubaguy> so I am +1 using json schema
13:10:20 <johnthetubaguy> just feels like the decorator you propose could just take the schema dictionary
13:10:22 <edleafe> json schema seems sane
13:10:35 <johnthetubaguy> for a specific version window
13:11:01 <alex_xu> johnthetubaguy: yea, only using json-schema is one of option, the implementation should be pretty close to the current poc: convert the query parameters into flat json data, then against with json-schema
13:11:03 <johnthetubaguy> or rather, just extend the existing input validation decorator to take parameter schema?
13:11:26 <johnthetubaguy> alex_xu: that seems the easiest, keep the it the same as we do for the body of the response
13:12:25 <johnthetubaguy> oh... I see now, you want the API code to read from an object
13:12:26 <sdague> how does openapi specify params?
13:12:40 <alex_xu> johnthetubaguy: yea
13:13:02 <alex_xu> then you needn't code like this "parsed = timeutils.parse_isotime(search_opts['changes-since'])" in the API code
13:13:07 <johnthetubaguy> alex_xu: we don't do that for the body of course, it feels like we should go the same way with both, whatever that is
13:13:15 <alex_xu> sdague: what do you mean 'openapi'?
13:13:30 <sdague> https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#other-parameters
13:14:08 <johnthetubaguy> I was just looking at; https://github.com/OAI/OpenAPI-Specification/blob/master/examples/v2.0/json/petstore-expanded.json#L34
13:14:16 <sdague> I was just trying to figure out if there was existing parameter specifications out there that could be reused so that we evolve closer to things like openapi
13:14:30 <sdague> johnthetubaguy: right
13:15:29 <sdague> I guess it's really just modified json schema
13:15:31 <johnthetubaguy> I have to say its tempting, but not sure I like the idea of a second DSL for validation
13:15:41 <sdague> which is pretty much close to what alex_xu already has
13:15:46 <johnthetubaguy> should be machine translatable between the two I guess
13:16:17 <sdague> I think the only other thing that should be considered though, is multi support, and if we can lock that down
13:16:28 <johnthetubaguy> yeah, the multi bit is the niggle
13:16:39 <johnthetubaguy> allowed in query string, but not in a json body
13:17:19 <johnthetubaguy> asdf?filter=bar,filter=foo
13:17:23 <sdague> right
13:17:48 <alex_xu> it works in the poc. not sure openapi yet
13:18:00 <sdague> https://review.openstack.org/#/c/388390/3/nova/api/openstack/compute/objects/servers.py@40
13:18:16 <sdague> so... this is worked around here by the oneOf
13:18:28 <alex_xu> yea...
13:18:46 <johnthetubaguy> ah, and webob does the mapping I guess?
13:18:47 <sdague> however, it would be nice if that was really {'type': 'string', 'enum': ['asc', 'desc'], 'multi': true}
13:18:59 <alex_xu> the bad thing is, currently, all the parameters accept multiple,but only the last one will be used....
13:19:16 <alex_xu> so...for the current version API...we need use 'oneOf' for all the parameters....
13:19:33 <johnthetubaguy> but do we currently work correctly with multiple?
13:19:45 <johnthetubaguy> I figgured it was just fall over in a heap
13:20:19 <alex_xu> yea
13:20:38 <alex_xu> sdague: do you want non-standard json-schema?
13:21:46 <sdague> alex_xu: I don't know
13:21:55 <sdague> it seems bad
13:22:09 <alex_xu> yea, me too
13:22:22 <sdague> maybe a macro function?
13:22:42 <sdague> 'sort_dir': multi_param({'type': 'string', 'enum': ['asc', 'desc']})
13:23:01 <sdague> that would build the oneOf json schema
13:23:03 <johnthetubaguy> yeah, something to stop the cut and paste, that looks nice, and easier to read
13:23:40 <alex_xu> emm...that looks like is more tidy
13:24:02 <sdague> yeh, and less likely to have a typo in the param format between the singleton and array
13:25:34 <alex_xu> so let me try another poc with micro function
13:25:46 <alex_xu> s/micro/macro/
13:26:12 <sdague> alex_xu: great
13:26:13 <johnthetubaguy> are we dropping the versioned object?
13:26:44 <johnthetubaguy> it doesn't feel like that would help us, unless we want to convert between versions of the API transparently, and I am not sure we want to do that
13:26:45 <alex_xu> I guess yes :)
13:27:39 <alex_xu> anyway, I will create another branch with microfunction without version object, then it is also good for people compare
13:27:46 <sdague> yeh, the versioned object here I think just makes it more complicated
13:28:01 <johnthetubaguy> do we need the decorator to be micro-version aware, just like the body validation?
13:28:14 <sdague> johnthetubaguy: yes, we will
13:28:15 <alex_xu> i guess so
13:28:39 <johnthetubaguy> is it worth adding it into the existing decorator? or is that going to get too messy?
13:28:44 <sdague> ip6 is actually the test case for this
13:29:06 <sdague> support for that being added to this parameter list would make the example compelte
13:29:09 <sdague> complete
13:29:15 <sdague> that was a param added in a mv
13:29:20 <alex_xu> yea
13:29:27 <johnthetubaguy> ah, good point
13:30:19 <alex_xu> and I guess we have bug for tags filter
13:30:21 <alex_xu> https://review.openstack.org/#/c/388391/3/nova/api/openstack/compute/servers.py@253
13:30:54 <alex_xu> it convert tag filter to list after 2.26...so before 2.26, it looks like wrong
13:31:16 <sdague> right
13:31:24 <sdague> anyway, this is a really good starting point
13:31:28 <johnthetubaguy> +1
13:31:51 <alex_xu> yea, fix all the mess
13:31:52 <sdague> I'm excited to see this work move forward, as the body validation has hugely helped on sanity checking and bug reduction
13:31:59 <sdague> alex_xu: thanks for pushing this forward
13:32:05 <alex_xu> sdague: np
13:32:48 <alex_xu> so when I have another poc I will ping you guys
13:33:05 <alex_xu> #action alex_xu get another poc without version object but with macro function
13:33:27 <alex_xu> so let us move on
13:33:31 <alex_xu> #topic Open
13:34:02 <alex_xu> I think we can just move to open. To check is there question want to bring up before summit?
13:34:15 <johnthetubaguy> the etherpad
13:34:21 <johnthetubaguy> #link https://etherpad.openstack.org/p/ocata-nova-summit-api
13:34:29 <johnthetubaguy> are we happy with the plan for what we will talk about?
13:34:39 <johnthetubaguy> basically agree scope, and assign people to work items
13:36:52 <alex_xu> johnthetubaguy: looks cool
13:39:00 <alex_xu> johnthetubaguy: the line 28 isn't belong to API doc I guess
13:40:08 <johnthetubaguy> alex_xu: I think that means how the API docs are very extension heavy right now
13:40:15 <johnthetubaguy> rather than being based on the API resources
13:40:22 <johnthetubaguy> although I thought a lot of that was fixed now
13:40:57 <johnthetubaguy> its largely a cut and paste from else where, so not sure on the source of that
13:41:22 <johnthetubaguy> oh wait, I missed out the non-doc bit
13:42:19 <johnthetubaguy> alex_xu: good catch, that looks better now I hope?
13:43:04 <alex_xu> johnthetubaguy: yea
13:45:21 <alex_xu> looks like a lot of work at here
13:46:54 <alex_xu> johnthetubaguy: looks good to me
13:47:24 <johnthetubaguy> cool, seems we have a session plan
13:48:02 <alex_xu> sdague: is that looks good to you?
13:48:28 <sdague> sure, though I won't be in barcelona unfortunately
13:48:54 <sdague> but I'm sure you and johnthetubaguy will have it covered
13:49:06 <alex_xu> ah, no :(
13:50:40 <alex_xu> maybe we will yell 'we need sdague' in the session :)
13:50:48 <sdague> heh
13:51:17 <alex_xu> ok, so anything more want to bring up?
13:52:12 <johnthetubaguy> I am good, beyond wishing everyone a safe journey
13:52:25 <alex_xu> johnthetubaguy: thanks, you too
13:53:14 <alex_xu> ok, let us close the meeting, johnthetubaguy see you in barcelona, and sdague see you after barcelona :)
13:53:18 <alex_xu> #endmeeting