13:00:02 <alex_xu> #startmeeting nova api
13:00:03 <openstack> Meeting started Wed Mar 23 13:00:02 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:04 <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:13 <alex_xu> who is here today?
13:00:19 <oomichi_> hi
13:00:20 <annegentle> o/
13:00:23 <gmann_> hi
13:00:26 <tojuvone> hi
13:00:26 <sdague> o/
13:00:29 <Kevin_Zheng> hi
13:00:51 <alex_xu> welcome everyone, let's start the meeting
13:00:57 <alex_xu> #topic Nova Microversion testing in Tempest
13:01:05 <alex_xu> gmann_: your turn first
13:01:14 <gmann_> ye
13:01:14 <cdent> o/
13:01:22 <annegentle> anyone have a link to the agenda handy?
13:01:32 <alex_xu> annegentle: https://wiki.openstack.org/wiki/Meetings/NovaAPI
13:01:33 <gmann_> so all necessary patches are merged now.
13:01:37 <annegentle> ty!
13:01:54 <gmann_> framework is in tempest/lib and 2.2 tests are already running on gate
13:02:07 <gmann_> u2.10 and 2.20 are up
13:02:22 <alex_xu> gmann_: cool, I guess just need some review on specific version test
13:02:35 <gmann_> so basically microverions tests can be implemented
13:02:36 <gmann_> yea
13:02:52 <oomichi_> nice :-)
13:02:57 <gmann_> creating doc for those also
13:02:59 <gmann_> #link https://review.openstack.org/#/c/261426/
13:03:13 <gmann_> oomichi_: Thanks for review. i updated that patch
13:03:24 <annegentle> woop woop doc :)
13:03:25 <oomichi_> gmann_: ok, will review it again later
13:03:35 <gmann_> That's all from my side
13:03:44 <alex_xu> gmann_: thanks for the works, really good progress!
13:03:53 <gmann_> annegentle: :)
13:03:55 <gmann_> alex_xu: npo
13:03:57 <gmann_> np
13:04:15 <alex_xu> #topic API Doc
13:04:22 <alex_xu> #link https://review.openstack.org/#/c/294078/
13:04:32 * edleafe walks in late
13:04:47 <gmann_> sdague: Thanks, i saw the devstack patch for capping the max microversion for mitaka.
13:04:55 <alex_xu> sdague: ^ I saw this in the agenda, so i start a separate topic for this, do you want to update something for this PoC
13:05:12 <sdague> alex_xu: yeh, we wanted to talk about this a bit for where we're getting
13:05:28 <sdague> I think this etherpad is probably a better link so far - https://etherpad.openstack.org/p/api-site-in-rst
13:05:52 <annegentle> also I invited karenb who has been working on fairy-slipper
13:05:58 <karenb> hi
13:06:01 * annegentle waves
13:06:07 <sdague> Last week I spent much of the week trying to see what it would look like to get our API docs over into RST more directly, plus a bit of structured content for things like tables
13:06:25 <karenb> I just started to look at your patch
13:06:30 <sdague> http://docs-draft.openstack.org/51/294151/4/check/gate-nova-docs/c2a264a//doc/build/html/rest_api/servers.html is an example of what the output looks like for the servers resource
13:06:44 * alex_xu poke oomichi_: we should have something similar with swagger also
13:06:50 * johnthetubaguy nodding with respect at the etherpad
13:07:03 <sdague> karenb: yeh, it's kind of a mess of a patch stack, so appologies in advance, this was mostly just pushing forward to see where we could get to
13:07:23 <karenb> I am a bit behind in understanding how this fits together
13:07:27 <annegentle> alex_xu: I think what we're finding though is swagger needs too much additional engineering to get an author/ publish workflow
13:07:29 <sdague> the crux of this is - RST files that look like this - https://raw.githubusercontent.com/openstack/nova/e8afd02ca66a0801974ba2199c5323736c606257/doc/source/rest_api/servers.rst
13:07:41 <sdague> ok, so how about I provide some common background
13:07:53 <karenb> are you trying to automate the generation of parameter definitions
13:07:54 <annegentle> karenb: yeah sorry for the "oh geez context"
13:08:12 <sdague> 2 weeks ago I spent some time looking at swagger and how it would apply to a long standing api like compute
13:08:16 <annegentle> mostly sdague and my concerns are around ongoing maintenance
13:08:24 <annegentle> both of content and tooling
13:08:28 <alex_xu> annegentle: yes
13:08:40 <sdague> and the problem is that swagger (and raml) is an API design tool, that has the side benefit of a docs framework
13:08:42 <annegentle> sdague: yeah it's the legacy APIs that aren't a fit
13:09:06 <sdague> however, if you don't start with swagger at your design, things like request parameter body is pretty rough to model
13:09:12 <karenb> yes, agreed.  there is some mismatch
13:09:21 <annegentle> karenb has dug in and yeah...
13:09:27 <oomichi_> sdague: yeah, I know
13:09:29 <alex_xu> sdague: yes
13:09:29 <sdague> because it expects a pretty strict model definition for in: body fields
13:09:36 <sdague> that we just don't have
13:10:07 <sdague> however, the WADL stack we have today is definitely holding us back from having docs that people can use
13:10:29 <annegentle> oh for sure
13:10:37 <alex_xu> sdague: wait, body just a json-schema, why we said it is rough to model?
13:10:40 <johnthetubaguy> adding microversion to WADL seem like a backwards step, so we need another route
13:10:42 <sdague> so... could we have a nearish term solution of getting over to RST
13:10:52 <oomichi_> sdague: I have another idea now, my prototype is trying to create swagger data from api router info instead of the code
13:11:00 <sdague> alex_xu: it's not just jsonschema
13:11:13 <oomichi_> sdague: https://review.openstack.org/#/c/296146/
13:11:16 <annegentle> oomichi_: that's the idea for fairy-slipper too but the engineering burden is then high
13:11:17 <karenb> json schema should be able to model the api, no?
13:11:33 <sdague> karenb: parts of it, probably
13:11:36 <annegentle> karenb: at least the request/ responses in this case I believe
13:11:46 <sdague> our jsonschema changes based on microversion though
13:11:47 <annegentle> (nova has those defined?)
13:11:50 <annegentle> sdague: ah ok
13:11:53 <sdague> some of them
13:11:53 <oomichi_> annegentle: yeah, we need to find a nice way to avoid it
13:12:30 <oomichi_> and I am trying to create a prototype for action api which is most difficult api for us
13:12:33 <sdague> anyway, I feel like the trap that WADL provided us was that we assumed that if we had some machine format, and a tooling pipeline, we end up with good docs
13:12:39 <oomichi_> to avoid the big burden
13:12:46 <sdague> but, it puts all the burden on the tooling pipeline
13:12:54 <gmann_> in json schema we can add description for each param etc but those are not yet complete info we can put there
13:12:55 <annegentle> the original idea for fairy-slipper was to automate making the reference info. however, in practice nothing was structured enough for "prose plus examples" I believe, and migrating showed us that.
13:13:02 <sdague> and doesn't let humans realize that sometimes things have to be explained differently to make sense
13:13:13 <annegentle> oomichi_: right on the /actions POST, ack
13:13:14 <sdague> there is very little human judgement on the output
13:13:20 <oomichi_> my idea is to provide swagger definition from REST API directly
13:13:31 <sdague> so, let's see what a content first approach looks like
13:13:35 <johnthetubaguy> so I think we need to have a concrete problems to focus on here, my choice would be: "how do we doc the microversions ASAP" and "how do we replace WADL quickly"?
13:13:40 <oomichi_> like kurbenetes
13:13:42 <johnthetubaguy> sdague: +1 lets look at that
13:14:03 <sdague> so, that would be RST that looks like this - https://raw.githubusercontent.com/openstack/nova/e8afd02ca66a0801974ba2199c5323736c606257/doc/source/rest_api/servers.rst
13:14:20 <sdague> and you will notice there is a rest_parameters stanza
13:14:41 <sdague> which is a list of parameters and types, that look up in a different file
13:14:51 <karenb> have you determined that swagger cannot replace wadl for compute?
13:14:57 <oomichi_> johnthetubaguy: nice point. I am thinking swagger definition of microversionscan be gotten easily if REST API
13:15:13 <oomichi_> johnthetubaguy: because we can specify microversion on nova api
13:15:13 <annegentle> karenb: it can, but only with a lot of extensions and then we have toolchain maintenance
13:15:13 <sdague> this is "just enough structure" to make generating tables in RST
13:15:40 <annegentle> oomichi_: also, these parameters.yaml files could be built from Swagger's parameters sections
13:15:50 <sdague> oomichi_: I 100% believe that swagger on the compute API is a wild goose chase. You are going to need to hack up swagger way outside the spec to make it work
13:15:59 <sdague> then you have to own an entire swagger publish toolchain
13:16:09 <sdague> we do not have the engineering for that
13:16:14 <gmann_> sdague: in that rst, can we use json schema for pram definition ?
13:16:28 <annegentle> #link http://paste.openstack.org/show/491575/
13:16:41 <annegentle> this is an example of some yaml pulled from a wadl migration
13:16:41 <sdague> gmann_: maybe, it actually looks very much like what fairy-slipper was producing in the wadl -> swagger conversion
13:17:00 <sdague> https://github.com/openstack/nova/blob/e8afd02ca66a0801974ba2199c5323736c606257/doc/source/rest_api/parameters.yaml
13:17:01 <annegentle> yeah
13:17:16 <sdague> I snagged the in: idea from swagger
13:17:55 <annegentle> to me, this might be an ideal way to prioritize "more contributors by getting off of wadl" while still borrowing what we can from swagger
13:17:56 <alex_xu> one idea is we generate swagger from code, and generate api doc like sdague's way
13:18:11 <annegentle> alex_xu: yeah but we've not got the engineering time for that
13:18:23 <sdague> here is the thing, generating swagger from code is engineering effort beyond getting content to the user
13:18:34 <annegentle> alex_xu: I mean, I would love if we could generate parameters.yaml from code!
13:18:38 <annegentle> that would be really cool
13:18:45 <johnthetubaguy> so I like sdague's approach as it opens up more options for the future, gets us microversion docs, and kills the WADL issue
13:18:48 <annegentle> but swagger from code, not so much
13:18:52 <sdague> my concern is what is the shortest path to get off WADL in a content first approach
13:18:56 <alex_xu> annegentle: ah, yes, something like that
13:19:24 <johnthetubaguy> yeah, lets get some docs where we control the tooling better, then start iterating some improvements, I love it
13:19:27 <sdague> and, because of the way we plug structured data into the RST with things like the rest_parameters stanza, that could clearly be swapped out later for other kinds of structured data
13:19:29 <oomichi_> another merit of swagger is for client api also if we provide it with rest api
13:19:33 <annegentle> and I know this is a nova-centric meeting, but of course I have to be the voice of reason for "ALL THE APIS" and I'm okay with RST plus YAML instead of RST plus Swagger for the legacy APIs that don't fit the model well.
13:19:34 <oomichi_> not only for doc
13:19:46 <sdague> oomichi_: all of those are theoretical benefits
13:19:49 <alex_xu> sdague: yes, and we won't generate another huge work for migating wadl to something else
13:19:52 <annegentle> oomichi_: yeah I know, but most people I talk to aren't huge fans of the generated clients
13:19:58 <annegentle> oomichi_: believe me, I've asked and asked
13:20:06 <annegentle> another thing this makes a bit harder is a "try it out" site
13:20:11 <oomichi_> because client code also can be genereted from swagger definition via rest api
13:20:14 <annegentle> but again, we would need more engineering time
13:20:37 <johnthetubaguy> so the problem we have is all our new APIs have zero docs
13:20:38 <sdague> oomichi_: that I think is the huge falacy that gave us WADL
13:20:44 <johnthetubaguy> RST gets us there real quick
13:20:48 <sdague> WADL was used for the same assumptions
13:20:51 <annegentle> oomichi_: yes but not unless you use x-post (an extended definition) and then engineer all tools specifically for your extensions
13:20:58 <sdague> and it turns out the consumers of our API docs are.... humans
13:21:00 <karenb> do you plan on using the sphinx tools to generate html from the rst
13:21:02 <annegentle> WADL was used for filtering requests
13:21:03 <sdague> and we are serving them well
13:21:10 <sdague> karenb: yes
13:21:12 <annegentle> and we need something that does one thing not multiple
13:21:27 <sdague> this is a normal sphinx pipeline from rst forward
13:21:31 <annegentle> karenb: yeah, there is a need for a sphinx extension to make nice tables from yaml
13:21:38 <annegentle> karenb: when sdague has created
13:21:49 <johnthetubaguy> annegentle: yeah, we need the docs, the other stuff we can worry about later
13:22:01 <sdague> if you pull that nova branch and run tox -e docs, it will build this html locally
13:22:02 <annegentle> johnthetubaguy: agreed, outcome is developer.openstack.org that's useful
13:22:28 <annegentle> karenb: what I'd like to do this week is try to use the openstackdocstheme and better CSS for tables
13:22:42 <annegentle> but want to be sure we have agreement on the path in general of course
13:22:58 <annegentle> we'll also talk about it at the API WG meeting this week
13:23:42 <sdague> right
13:23:50 <oomichi_> annegentle: aren't there any projects which use swagger yet?
13:24:00 <sdague> I think the important thing to focus on is how soon can we get real docs to our users
13:24:03 <johnthetubaguy> it feels like this is our only chance of getting good microversion docs by the end of the cycle, so it excites me
13:24:05 <johnthetubaguy> sdague: +1
13:24:07 <annegentle> oomichi_: magnum has a swagger file, but their API might be redesigned
13:24:21 <oomichi_> annegentle: ah, ok. thanks for the info
13:24:30 <annegentle> oomichi_: and sahara has one generated with a pecan plugin I believe
13:24:40 <karenb> do you have detailed docs on the use of microversions
13:25:00 <karenb> I am not sure how that is related to your api model
13:25:25 <annegentle> oomichi_: we have a patch in progress to build the migrated swagger files
13:25:27 <annegentle> #link http://docs-draft.openstack.org/59/286659/9/check/gate-build-swagger/95e743a/swagger/compute-v2.1-swagger/index.html
13:26:01 <oomichi_> annegentle: cool, thanks again :-)
13:26:04 <sdague> karenb: what kind of info are you looking for?
13:26:09 <johnthetubaguy> karenb: I tend to point people at sdague's blog post: https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/
13:26:17 <sdague> yeh, that link is good background
13:26:30 <alex_xu> karenb: and this is also one http://developer.openstack.org/api-guide/compute/microversions.html
13:26:32 <sdague> and then there are details in the tree a bit on the ones we've landed
13:26:49 <annegentle> #link http://docs.openstack.org/developer/nova/api_microversions.html
13:26:54 <karenb> what resources are available on what version, how do you access these versions, etc
13:26:59 <annegentle> ^^ yeah that one is for contributor devs
13:27:25 <johnthetubaguy> http://developer.openstack.org/api-guide/compute/microversions.html
13:27:47 <johnthetubaguy> oh wait, yeah, thats the same thing, the API user guide
13:27:54 <alex_xu> ah, looks like we already have a lot of doc for microverions :)
13:28:03 <gmann_> :)
13:28:04 <sdague> except for the user :)
13:28:18 <alex_xu> sdague: this is for user http://developer.openstack.org/api-guide/compute/microversions.html
13:28:20 <annegentle> only one for the user and no reference info :)
13:28:38 <johnthetubaguy> yeah, no reference info yet, thats the aim here
13:28:42 <annegentle> but honestly, this is firstly about maintainable content
13:28:44 <sdague> oomichi_: we will not that on http://docs-draft.openstack.org/59/286659/9/check/gate-build-swagger/95e743a/swagger/compute-v2.1-swagger/index.html doesn't have response parameters
13:28:46 <gmann_> yea
13:29:03 <sdague> alex_xu: it's not, it doesn't tell them what's in the various microversions
13:29:17 <oomichi_> sdague: yeah, nice point.
13:29:24 <alex_xu> sdague: ah, I got it
13:29:32 <annegentle> oomichi_: and that's part of the findings as we got deeper into swagger...
13:29:42 <annegentle> what got us here won't get us there? Or something?
13:29:52 <oomichi_> sdague: we need to migrate jsonschema from tempest if swagger
13:30:13 <oomichi_> sdague: then the ownership of jsonshema discussion again..
13:30:19 <sdague> oomichi_: again, that's a whole lot of engineering effort before we ever actually solve any problems for our users
13:30:24 <alex_xu> oomichi_: ah, yes, that is another huge work for support swagger :(
13:30:26 <sdague> we have to be user centric here
13:30:39 <annegentle> right...
13:30:49 <sdague> how do we solve that fact that anyone who wants to write an application with nova has to read the nova source code today
13:30:56 <sdague> solve for that first
13:31:17 <sdague> then look at ways we might optimize our storage / generation of some of that data
13:31:18 <oomichi_> sdague: yeah, I know. maybe swagger thing is long-term work on nova. not so soon ;-)
13:31:31 <annegentle> oomichi_: yeah, that's my sense of it
13:31:58 <alex_xu> but I also hope we can show json-schema in the doc, even with sdague's propose
13:32:12 <sdague> alex_xu: as a phase 2, probably
13:32:12 <gmann_> alex_xu yea that will be nice
13:32:40 <karenb> somehow it would be good to generate a schema to a specification whether swagger or something else
13:32:43 <annegentle> alex_xu: yeah I don't sense we're cutting off innovations there
13:32:48 <karenb> it makes your api interoperable
13:33:04 <annegentle> karenb: yeah, and interoperability is needed for OpenStack DefCore
13:33:13 <annegentle> meeting the tests.
13:33:15 <oomichi_> but here are tempest-cores also, it is not so hard :)
13:33:15 <sdague> karenb: I agree
13:33:26 <annegentle> oomichi_: good :)
13:33:38 <sdague> however, I want to make sure we don't get caught up on the schema before the user docs
13:33:49 <alex_xu> current odc didn't tell user what is request and response format
13:34:20 <alex_xu> sdague: yea, got it, step by step
13:34:31 <alex_xu> s/odc/doc/
13:34:42 <sdague> as a for instance, just telling people 3 of the server parameters are only available in later versions of nova
13:34:45 <gmann_> sdague: but if we do schema thing later then would not it be duplicate effort to put all those param info in rst and yaml
13:35:16 <sdague> http://docs-draft.openstack.org/51/294151/4/check/gate-nova-docs/c2a264a//doc/build/html/rest_api/servers.html#id5
13:35:16 <gmann_> and then ref those to schema
13:35:52 <sdague> gmann_: we can either optimize for getting working docs, or optimize for data formats
13:36:13 <annegentle> maintainable docs
13:36:15 <gmann_> sdague: from schema ('required'), we can show the mandatory and optional param there
13:36:20 <sdague> and I believe that if we optimize for working docs, we'll open up the api docs to new contributors that can help
13:36:21 <annegentle> (not arguing, heh)
13:36:46 <sdague> instead of kicking them in the face with a pile of hard to understand sgml
13:36:58 <gmann_> humm
13:37:09 <edleafe> annegentle: if they aren't maintainable, they won't be working (for long)
13:37:21 <annegentle> aww sdague there are still over 100 contribs to the WADL each release, but yes we need to get off of it
13:37:38 <sdague> annegentle: they are, and I commend their hero level of dedication to get there
13:37:55 <annegentle> one other Q I want to ask this group, is it easier in some ways to contribute to YAML and json schema files instead of RST due to English-as-a-second language?
13:38:32 <annegentle> I want to consider that many many contributors to the API reference don't mind it because it's like filling in a form.
13:38:41 <annegentle> swagger would have given us the "form"
13:38:48 <annegentle> but... the API doesn't quite fit.
13:38:59 <annegentle> does that make any sense or is it a needless worry?
13:39:06 <sdague> annegentle: possibly, but at the end of the day you still need to write english on descriptions
13:39:14 <alex_xu> English will always a problem, you need English explain the thing
13:39:20 <annegentle> sdague: so, so true
13:39:37 * alex_xu 's problem
13:39:51 <annegentle> alex_xu: yeah... I don't want to be inconsiderate of a big group of contributors here just because I write a ton
13:40:04 <oomichi_> annegentle: it is easy to understand the code (json-schema, also) than English for me always :)
13:40:05 <gmann_> apart from english, i feel each developer like json nd yaml format(even with description  than witting all in rst :)
13:40:14 <annegentle> gmann_: :)
13:40:25 <alex_xu> oomichi_: me too :)
13:40:36 <edleafe> oomichi_: me too, sometimes :)
13:40:44 <annegentle> ok yeah... to me, this does mean it's worthwhile to eventually enable something like Swagger.
13:40:55 <alex_xu> edleafe: when you ready my commit message
13:40:56 <sdague> however, so far that has failed to make an API site that anyone would use
13:41:02 <annegentle> but! There's a ton of work on parameters.yaml to get those up to par
13:41:11 <annegentle> yeah I think this is a decent compromise
13:41:16 <edleafe> alex_xu: :)
13:41:23 <oomichi_> annegentle: yeah, it is easy to understand api design from sample files actually
13:41:37 <alex_xu> parameters.yaml should convert from wadl?
13:41:49 <oomichi_> the body structures can be understandable from sample files
13:41:49 <karenb> getting the content pieces right (req+response examples, params) is important
13:41:51 <annegentle> alex_xu: well, I'd like to find someone who would investigate
13:41:57 <annegentle> maybe it's sdague?
13:41:58 <sdague> karenb: yes, absolutely
13:42:08 <sdague> alex_xu: I would hope so
13:42:10 <oomichi_> karenb: agree
13:42:12 <annegentle> maybe karenb can take a look?
13:42:36 <sdague> I believe the fairy-slipper wadl -> swagger built content almost exactly like it
13:42:44 <sdague> and we can tweak things to make that match
13:43:23 <karenb> I need to look at parameters.yaml
13:43:32 <sdague> this was an attempt to build a semi structured format that would be readonable to get over from our current bits
13:43:38 <annegentle> sdague: for now, parameters.yaml was just one idea right?
13:43:45 <annegentle> sdague: ok
13:43:50 <sdague> so that the conversion could be quick
13:44:02 <sdague> annegentle: yes, it's just the current thing I built that worked
13:44:04 <oomichi_> sdague: yeah, I agree
13:44:11 <karenb> wadl-> swagger has a model that is slightly different than swagger
13:44:15 <sdague> if we need field changes in it, that's all negotiable
13:44:24 <karenb> you could do anything with it
13:44:54 <annegentle> malleable!
13:44:55 <sdague> karenb: yeh, annegentle showed me the json there and it looked really similar to https://github.com/openstack/nova/blob/e8afd02ca66a0801974ba2199c5323736c606257/doc/source/rest_api/parameters.yaml
13:45:41 <sdague> and the content / structure of that file is just inside the rest_parameters sphinx extension, we can make it whatever makes sense
13:46:25 <sdague> I also expect that the tools will get us about 90% of the way in a conversion, then we'll just have to clean up the final bits in a sprint
13:46:35 <annegentle> there will definitely be cleanup
13:46:44 <annegentle> but a sprint per project would get us there
13:47:16 <karenb> sure.  swagger2rst from fairy-slipper also creates custom rst directives and
13:47:37 <karenb> collects the various rst pieces together
13:47:42 <karenb> the parsing is not complicated
13:47:50 <sdague> karenb: cool
13:47:54 <annegentle> karenb: oh yeah
13:48:53 <annegentle> (were there other agenda items?)
13:48:59 <alex_xu> yes
13:49:06 <sdague> yeh, we kind of monopolized here :)
13:49:11 <annegentle> ok didn't want to take over :) sorry
13:49:15 <alex_xu> if we are cool for the doc, then we jump to open
13:49:27 <sdague> sorry, but it was a big change in direction and wanted to get discussion going
13:49:42 <annegentle> yeah appreciate it all
13:49:49 <alex_xu> sdague: yes, anyway we want to discuss newton work, the doc is part of that
13:50:15 <alex_xu> #topic open
13:50:44 <alex_xu> I think we didn't have time discussion other newton item today. Let us go through those next week
13:50:47 <cdent> after discussion yesterday with sdague I've created this: https://github.com/cdent/microversion-parse
13:50:59 <cdent> that might be relevant to some folk
13:51:00 <sdague> cdent: thanks again for that
13:51:19 <sdague> alex_xu: do you have the etherpad linke for newton api items?
13:51:21 <cdent> it's pending infra-ness at https://review.openstack.org/296046
13:51:32 <alex_xu> sdague: https://etherpad.openstack.org/p/newton-nova-api-ideas
13:51:48 <alex_xu> johnthetubaguy also put something in https://etherpad.openstack.org/p/newton-nova-summit-ideas
13:51:49 <sdague> we should put the standard header parsing as an item
13:52:07 <alex_xu> sdague: microversion's header?
13:52:52 <sdague> the new guideline on OpenStack-API-Version
13:53:04 <alex_xu> sdague: ah, yea
13:53:12 <alex_xu> sdague: it's in line 23
13:53:18 <sdague> that's what cdent's library helps with
13:53:42 <alex_xu> cdent: cool
13:54:18 <gmann_> cdent: looks interesting , will check in detail tomorrow.
13:54:30 <cdent> thank alex_xu, gmann_
13:54:35 <cdent> thanks :)
13:54:53 <gmann_> so it will be candidate for all project's microversion header parsing right
13:55:05 <sdague> gmann_: yes
13:55:06 <gmann_> i mean for api-wg
13:55:27 <gmann_> sdague: ok, will be good for tempest microversion testing too
13:55:38 <alex_xu> if any people have real 'open' item, please bring up, otherwise you will lose the chance :(
13:57:11 <alex_xu> ok, I guess no...
13:57:24 <alex_xu> Kevin_Zheng: there is one https://review.openstack.org/#/c/293790/ I guess you put it here
13:57:36 <Kevin_Zheng> yes
13:57:47 <Kevin_Zheng> if there is still time
13:57:47 <alex_xu> Kevin_Zheng: anything we can help?
13:58:00 <alex_xu> Kevin_Zheng: sorry, 3 mins :(
13:58:18 <Kevin_Zheng> yes last week I talk about your ideas about force stop instances
13:58:28 <Kevin_Zheng> I put up a spec
13:59:12 <alex_xu> Kevin_Zheng: ah, cool
13:59:36 <alex_xu> I will try to reach that
13:59:37 <Kevin_Zheng> Thanks, looks like you guys have alot of things important than this
13:59:47 <Kevin_Zheng> yes, its not in a hurry
14:00:01 <Kevin_Zheng> Thanks again
14:00:11 <alex_xu> Kevin_Zheng: no worries, free to bring question at here
14:00:19 <alex_xu> sorry, it's time to close the meeting
14:00:24 <Kevin_Zheng> NP
14:00:29 <alex_xu> thanks all!
14:00:31 <alex_xu> #endmeeting