12:00:09 <alex_xu> #startmeeting nova api
12:00:09 <openstack> Meeting started Tue Oct 20 12:00:09 2015 UTC and is due to finish in 60 minutes.  The chair is alex_xu. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:12 <openstack> The meeting name has been set to 'nova_api'
12:00:18 <alex_xu> who is here today?
12:00:24 <edleafe> o/
12:00:25 <johnthetubaguy> hi
12:00:28 <Kevin_Zheng> hi
12:00:42 <alex_xu> hello everyone!
12:00:51 <jichen> o/
12:01:05 <alex_xu> #topic actions from last meeting
12:01:22 <alex_xu> Action: alex_xu file bug for wadl doc problem, and work with Kevin_Zheng on fix them
12:01:31 <alex_xu> also gmann help on this
12:01:38 <alex_xu> #link https://etherpad.openstack.org/p/nova-v2.1-api-doc
12:01:50 <alex_xu> all the problem which I found, already fixed
12:01:57 <alex_xu> also part of them already merged
12:02:12 <alex_xu> Kevin_Zheng, gmann thanks for fixing
12:02:20 <gmann_> sorry for late
12:02:23 <Kevin_Zheng> Your welcome
12:02:26 <johnthetubaguy> ah, great stuff
12:02:35 <alex_xu> Action: alex_xu create bp and etherpad to track the concept doc work
12:02:35 <Kevin_Zheng> you're
12:02:44 <alex_xu> #link Action: alex_xu create bp and etherpad to track the concept doc work
12:02:49 <alex_xu> oops
12:02:51 <alex_xu> #link https://blueprints.launchpad.net/nova/+spec/complete-todo-in-api-concept-doc
12:03:03 <alex_xu> ^ I just created the bp
12:03:29 <alex_xu> please free feel to take any todo from api concept doc
12:03:43 <johnthetubaguy> just approved it
12:03:53 <alex_xu> johnthetubaguy: thanks!
12:04:16 <alex_xu> we probably we dicussion how to get more people join those works, we have a lot of doc work in M
12:04:23 <gmann_> yea
12:04:27 <johnthetubaguy> +1 its a good thing to talk about that the summit
12:04:37 <alex_xu> Action: gmann_ will creae BP and etherpad to track the work merge api sample test and run all the extensions
12:04:42 <johnthetubaguy> we have a low hanging fruit doc, but this is not really that
12:04:48 <gmann_> did today
12:04:50 <alex_xu> gmann_: how was that?
12:04:53 <gmann_> #link https://blueprints.launchpad.net/nova/+spec/api-sample-tests-with-all-extensions
12:04:55 <alex_xu> johnthetubaguy: yea
12:05:05 <alex_xu> gmann_: cool, thanks
12:05:23 <alex_xu> I remember there already have a patch up
12:05:33 <gmann_> johnthetubaguy, please aprove that too :)
12:05:43 <gmann_> i also started base patch on that- https://review.openstack.org/#/c/237400/
12:05:46 <johnthetubaguy> -1067 nice
12:06:00 <alex_xu> gmann_: cool
12:06:11 <johnthetubaguy> did those removed tests just become redundant I guess?
12:06:52 <johnthetubaguy> oh, I see now, cools
12:06:58 <gmann_> johnthetubaguy, yea redundant tests written for separate extensions will be removed
12:07:09 <johnthetubaguy> approved that blueprint
12:07:25 <gmann_> and best will be we will get rid of all extension list flag setting for v2
12:07:32 <alex_xu> I'm thinking how we test bdm or scheduler-hints thing
12:07:35 <gmann_> johnthetubaguy, Thanks
12:08:01 <alex_xu> will all bdm and scheduler-hints showing one single servers api sample test?
12:08:21 <gmann_> alex_xu, may be , i need to check those
12:08:43 <alex_xu> gmann_: yea, we only have one sample test, but we need show all of those parameters
12:08:59 <gmann_> yes
12:09:15 <alex_xu> ok, cool, let's move on
12:09:17 <gmann_> for each resource single tests will all param in request response
12:09:17 <alex_xu> Action: johnthetubaguy to sort out etherpads for API session, and send link to alex_xu
12:09:34 <alex_xu> #link https://etherpad.openstack.org/p/mitaka-nova-api
12:09:44 <alex_xu> johnthetubaguy: thanks for the etherpad
12:09:59 <sdague> hey folks (sorry, was working on etherpads) :)
12:10:05 <alex_xu> also thanks to sdague, he already list all the things in the etherpad
12:10:06 <gmann_> alex_xu, johnthetubaguy cool
12:10:21 <alex_xu> sdague: yea, cool etherpad :)
12:10:22 <gmann_> Thanks guys, it will be great
12:10:42 <alex_xu> I didn't found anymore I can add to etherpad
12:10:52 <sdague> johnthetubaguy: you happy with that etherpad agenda?
12:11:06 <alex_xu> #topic Summit API Session
12:11:13 <sdague> I'll probably delete the little agenda bit at the bottom
12:11:13 * alex_xu jump the topic directly
12:11:26 <johnthetubaguy> sdague: looks close, I keep meaning to loop back around all of those etherpads to see where we are add
12:11:46 <johnthetubaguy> sdague: that was more a consitency thing, I think we just move pre-reading to the top, and the rest is your agenda
12:11:51 <sdague> johnthetubaguy: ok, I think we're probably not going to get to the feature classification bits yet
12:11:55 <sdague> yeh, that's fine
12:12:22 <johnthetubaguy> sdague: yeah, I am thinking about adding a testing session to replace the final unconference session
12:12:37 <johnthetubaguy> we need to push on testing, thinking about how to make it happen
12:12:52 <sdague> I also think I found another person in our team that's interested in helping here, including on the docs side. I think trying to recruit more folks to help on docs this cycle will be an important part of this.
12:13:06 <alex_xu> sdague: +1
12:13:12 <gmann_> sdague, yea
12:13:27 <alex_xu> looks like we still didn't have microversion test on tempest
12:13:36 <johnthetubaguy> alex_xu: we should both talk to the OSIC people about making this a priority
12:13:40 <oomichi> yeah, right
12:13:44 <johnthetubaguy> alex_xu: that would be a good add, at least one of those
12:13:45 <gmann_> alex_xu, yea, we have 1 session for that
12:13:49 <oomichi> and we have qa-session for microversion test
12:13:51 <alex_xu> johnthetubaguy: yea
12:14:04 <alex_xu> gmann_: oomichi cool
12:14:25 <gmann_> I have WIP patch for microversion top bottom and changed testing
12:14:29 <johnthetubaguy> oomichi: ah, OK, can you report back to the nova meetup on the outcome of that maybe?
12:14:31 <oomichi> #link https://etherpad.openstack.org/p/mitaka-nova-api
12:14:37 <oomichi> oops, wrong
12:14:39 <johnthetubaguy> gmann: you mean in tempest or nova?
12:14:43 <oomichi> #link http://mitakadesignsummit.sched.org/event/10827a8275cb824c9e2a0fd2ee9c4ae1#.ViYwIm48qaw
12:14:51 <oomichi> in tempest
12:14:53 <gmann_> johnthetubaguy, on nova
12:15:04 <johnthetubaguy> gmann: do we have a blueprint for that?
12:15:24 <gmann_> as we discussed in Vancouver that nova functional test should tests top bottm an changed version
12:15:33 <gmann_> not yet,
12:15:38 <johnthetubaguy> gmann: agreed with the direction, just thinking about a specless blueprint to track it
12:15:49 <gmann_> sure will do tomorow
12:15:49 <johnthetubaguy> gmann: send me a link, and I can get that approved for you
12:15:57 <gmann_> johnthetubaguy, sure
12:16:00 <johnthetubaguy> :)
12:16:04 <gmann_> johnthetubaguy, Thanks
12:16:17 <sdague> brb, baby waking up.
12:16:28 <gmann_> sdague, :)
12:16:32 <oomichi> sdague: cool :-)
12:16:36 <alex_xu> #action gmann_ create bp for microversion top bottom and changed testing
12:16:48 <gmann_> alex_xu, Thansk.
12:16:53 <alex_xu> sdague: heh, baby is urgent thing
12:16:58 <alex_xu> gmann_: np
12:17:26 <alex_xu> any more question on summit api session?
12:17:37 * edleafe doesn't miss having babies run my schedule
12:17:43 <johnthetubaguy> sounds like a good set of things, thanks for the prep on that
12:18:15 <alex_xu> something like remove v3 cleanup looks like needn't list at there
12:18:28 <alex_xu> yea, really thanks to sdague
12:18:46 <alex_xu> so let's move on
12:18:50 <alex_xu> #topic API Documentation
12:19:21 <alex_xu> for generate swagger doc, current we have two poc
12:19:40 <alex_xu> one is generated from nova code base, we already talk about that in last week
12:19:46 <alex_xu> #link  https://review.openstack.org/233446
12:20:07 <alex_xu> another one is generate from tempest log, which thanks to oomichi
12:20:12 <alex_xu> #link  https://review.openstack.org/235092
12:20:22 <alex_xu> oomichi: ^ do you want to talk about that?
12:20:38 <oomichi> alex_xu: not so many.
12:20:41 <johnthetubaguy> so my thoughts on this stuff are quite nova specific
12:20:51 <johnthetubaguy> look at these two, I like this approach
12:20:58 <johnthetubaguy> (1) generate docs from the code
12:21:09 * sdague is back
12:21:09 <oomichi> alex_xu: maybe it is nice to make the combination of both for covering all cases
12:21:13 <johnthetubaguy> (2) have tests that run to check the docs
12:21:32 <johnthetubaguy> (3) have a way to check tempest coverage vs the docs
12:21:38 <johnthetubaguy> or something like that
12:21:46 <oomichi> johnthetubaguy: nice idea
12:21:52 <johnthetubaguy> basically, +1 to what oomichi said about the combo
12:22:00 <alex_xu> oomichi: yea
12:22:04 <gmann_> yea that will be cool thing
12:22:05 <alex_xu> johnthetubaguy: sounds cool
12:22:12 <oomichi> johnthetubaguy: and it is nice to improve test coverage also for tempset by using both:-)
12:22:14 <johnthetubaguy> I like that you commit the code in nova, and we get some docs and testing automatically in that commit
12:22:17 <gmann_> i like 3 part more
12:22:25 <sdague> alex_xu: instead of using a decorator, can we use a docstring?
12:22:32 <johnthetubaguy> sdague: +1
12:22:39 <alex_xu> sdague: yea, we can
12:22:51 <sdague> even if that docstring needs a marker in it like: ::api_doc::
12:22:53 <alex_xu> sdague: or your mean all the docs, like for input, output, error code?
12:23:04 <sdague> and the chunk after it is what we consider for swagger
12:23:18 <sdague> I feel like instead of @wsgi.doc
12:23:27 <sdague> in looking at https://review.openstack.org/#/c/233446/6/nova/api/openstack/compute/keypairs.py,cm
12:23:42 <johnthetubaguy> sdague: I wonderd about removing the param, use first line as the short title, and the rest as the description
12:23:56 <sdague> johnthetubaguy: yeh, maybe
12:23:56 <alex_xu> sdague: yea, that's one also want to docstr to instead
12:24:15 <alex_xu> johnthetubaguy: +1
12:24:16 <edleafe> sdague: decorators are easier to understand than some nested docstring. What is the concern with them?
12:24:22 <gmann_> or how about adding description in request schema
12:24:25 <oomichi> +1 for docstring
12:24:38 <johnthetubaguy> edleafe: its prose in a decorator, its super hard to read
12:24:39 <oomichi> on my PoC also, docstring is used
12:24:46 <gmann_> if we have schema for all APIs
12:24:53 <oomichi> for explaining overview of API
12:25:03 <sdague> edleafe: yeh, being in a decorator means that it's going to push people towards brevity
12:25:19 <edleafe> johnthetubaguy: ah, thanks. Didn't know you were aiming for verbosity
12:25:31 <sdague> being in a docstring is going to allow for people to expand and even add things like examples
12:25:46 <gmann_> we have have each param description in schema along with general one
12:25:59 <alex_xu> actually we need doc for request schema, response schema, url params, query params, error status code, success code, currently implement looks mess, all of those thing spread in many place
12:26:12 <johnthetubaguy> yeah, I like the params being described in the schmea
12:26:32 <gmann_> ye, so we have type and their description all in one place
12:26:36 <johnthetubaguy> so I think it needs to be close to where things are modified
12:26:48 <oomichi> yes, it is nice to write the explanation of each param at close place
12:26:49 <johnthetubaguy> when you change the param, you change the schema, so that feels OK
12:27:17 <oomichi> johnthetubaguy: +1, nice to maintain the code
12:27:18 <alex_xu> johnthetubaguy: yea, that is good point, also think about that in the beginning
12:27:22 <johnthetubaguy> but honestly, I think we just need to pick one and try it, and evolve it as we go
12:27:32 <gmann_> yea
12:27:46 <alex_xu> cool
12:27:57 <sdague> so, personally, I think we should focus on the docs close to the code. The schema should just be enforcement and not description.
12:27:59 <johnthetubaguy> just, yeah, my preference is close to where you normally make modifications, for the best hope of folks noticing the need for changing the doc
12:28:44 <sdague> anyway - https://review.openstack.org/#/c/233446/6/nova/api/openstack/compute/keypairs.py,cm if it used docstrings instead of decorators would be super useful I think
12:28:55 <gmann_> sdague, but param type and thir checking on schema side than code
12:29:00 <johnthetubaguy> sdague: I am thinking the schema is close enough, as we probably change the schema if the docs need to change, but yeah, if it could get in the code, then maybe thats better
12:29:12 <oomichi> sdague: what "not description" mean?
12:29:50 <oomichi> johnthetubaguy: yeah, schema is nice place to write the description for each param
12:29:50 <sdague> oomichi: describing each parameter inside the schema seems like the wrong places to do that
12:30:18 <oomichi> sdague: discussion point
12:30:19 <sdague> because the schema is really the test
12:30:23 <sdague> in some ways
12:30:31 <sdague> you want to describe your intent elsewhere
12:30:37 <sdague> and then the schema enforces it
12:30:55 <johnthetubaguy> well the schema drives the param checking code, the response schema is much less clear
12:31:00 <sdague> if you only describe your intent in the enforcement layer, you tend to slip up and change enforcement an intent
12:31:17 <johnthetubaguy> hmm, true
12:31:18 <gmann_> sdague, schema has all their type range etc defined
12:31:30 <oomichi> sdague: uhm, difficult
12:31:32 <sdague> gmann_: right, sure, and that's fine
12:31:49 <johnthetubaguy> anyways, I think this is one we need to see in code first
12:32:01 <oomichi> sdague: most info of each param is written in schema
12:32:05 <oomichi> gmann_: yeah
12:32:07 <johnthetubaguy> need it to look non-horrible, ideally
12:32:16 <sdague> yeh, anyway, lets look at how it all comes together
12:32:20 <sdague> so more poc
12:32:25 <sdague> and see what each stage looks like
12:32:25 <johnthetubaguy> yeah
12:32:30 <alex_xu> ok, cool
12:32:31 <gmann_> yea
12:32:37 <oomichi> nice step
12:32:48 <johnthetubaguy> lets layer on the param bits, see how it looks
12:32:49 <sdague> because it's important that the generated docs feel coherent
12:32:56 <johnthetubaguy> sdague: +1
12:32:58 <sdague> and it's important the improving the docs is straight forward
12:33:10 <sdague> because if it's editing in a million places, no one will improve it
12:33:25 <oomichi> sdague: big +1
12:33:37 <sdague> we want to grow a class of contributors that can improve our docs without understanding our code
12:33:48 <oomichi> nice api doc will make us avoid wrong API usages
12:33:53 <alex_xu> sdague: +1
12:33:54 <johnthetubaguy> agreed, certainly for clarity, etc
12:33:57 <gmann_> sdague, yup
12:34:16 <alex_xu> ok, cool, so let's move on?
12:34:19 <gmann_> and can implement tests with those doc without code reading which i always do :(
12:34:19 <sdague> yep
12:34:28 <johnthetubaguy> gmann_: +1
12:34:35 <alex_xu> heh
12:34:37 <alex_xu> #topic Remove project_id from URL
12:34:47 <alex_xu> this is another important work
12:34:53 <alex_xu> sdague: do you want to talk about it?
12:35:18 <alex_xu> I added this into the agenda, thinking of this is something should tracked by api team
12:35:41 <sdague> alex_xu: sure
12:36:04 <sdague> so in support of the service catalog tng work, I spent last week trying to see what's required to remove project_id from nova
12:36:09 <sdague> it's not too bad
12:36:27 <sdague> #link https://etherpad.openstack.org/p/removing-project-id-in-nova-urls
12:36:28 * johnthetubaguy wonders if we should rename to making project_id optional in the URL
12:36:32 <sdague> that was my working document
12:36:46 <sdague> johnthetubaguy: yeh, that's fair, it's making it optional
12:36:48 <alex_xu> sdague: cool
12:36:49 <gmann_> sdague, and we need to support url with project_id too by ignoring them ? or m missing something
12:37:14 <alex_xu> we aren't removing url with new microversion?
12:37:15 <sdague> the only place we care about project_id, mostly, is during one enforcement check
12:37:55 <johnthetubaguy> alex_xu: so I think we need to backport this change to previous versions, but thats maybe a different discussion
12:38:03 <sdague> https://github.com/openstack/nova/blob/81fbb34e2544b26ae72f7eee3841b4024d22896f/nova/api/openstack/wsgi.py#L813-L821
12:38:11 <alex_xu> johnthetubaguy: ok
12:38:28 <sdague> yeh, we have to figure out our version signaling on this
12:38:40 <oomichi> easy to implement it with ProjectMapper instead of PlainMapper
12:38:49 <gmann_> because response contain those in namespace or links etc
12:38:52 <sdague> my feeling right now is that we should add a microversion to indicate that project_id is optional from here on out
12:39:11 <johnthetubaguy> sdague: +1 my gut says the same thing
12:39:22 <sdague> that's one of the reasons the patch is Do Not Merge
12:39:25 <gmann_> sdague, +1 for version to publish
12:39:53 <oomichi> sdague: if specified microversion doesn't support it but client doesn't pass project-id, nova will return 400?
12:40:01 <johnthetubaguy> the other thing, is we probably don't want to remove this in a microversion, because of all the folks using the old service catalog entries, as folks transition
12:40:07 <sdague> oomichi: no
12:40:20 <johnthetubaguy> oomichi: its just optional, I think
12:40:26 <oomichi> sdague: the microversion is just for publishing
12:40:29 <sdague> oomichi: or at least that wasn't my intent
12:40:36 <sdague> because this involves changing the mapper
12:40:45 <sdague> so it's kind of hard to do it runtime
12:40:48 <oomichi> sdague: yeah, right
12:41:01 <oomichi> sdague: from implemenation side
12:41:06 <sdague> yeh
12:41:29 <alex_xu> just for publishing is good idea
12:41:36 <sdague> it's a compromise, but unless we want to massively redo Routes, I don't think we can get perfect microversion behavior
12:41:50 <johnthetubaguy> so its something we though about doing in v3 right, but dropped it, making it optional/ignored seems like a better solution
12:41:51 <sdague> so just using the microversion as the signaling element seemed fine
12:41:56 <johnthetubaguy> yeah
12:42:05 <sdague> johnthetubaguy: yeh, it was not going to be there in v3
12:42:23 <oomichi> sdague: yeah, my small concern is that that doesn't seems perfect for microversion
12:42:25 <johnthetubaguy> so thinking about signalling, I guess the big signal is actually in the service catalog?
12:42:46 <sdague> johnthetubaguy: yes
12:43:00 <sdague> except, so many applications hard code past the service catalog
12:43:08 <sdague> so we can't just depend on that
12:43:24 <gmann_> hummm
12:43:27 <johnthetubaguy> yeah, +1
12:43:42 <johnthetubaguy> many signals good
12:44:04 <sdague> the first session of the design summit is a double session on the service catalog tng work
12:44:21 <sdague> I'm mostly going to leave this patch in the DNM state until after summit
12:44:30 <johnthetubaguy> yeah, +1
12:44:30 <sdague> and just make sure we have broad agreement on the big plan
12:44:44 <alex_xu> agree
12:44:48 <sdague> project_ids being optional is an early bit that projects will need to do
12:44:51 <edleafe> yeah, I'd like to hear all the concerns
12:45:11 <sdague> so assuming no giant roadblocks, we should be able to clean this up and merge by M-1
12:45:35 <sdague> https://etherpad.openstack.org/p/mitaka-service-catalog-session is the etherpad for service catalog session
12:46:07 <alex_xu> cool
12:46:27 <johnthetubaguy> so for context, we use Repose in front of our API, I think there will need to be changes to drop the project_id in the URL
12:46:37 <sdague> johnthetubaguy: right, probably
12:46:59 <gmann_> yea, in links it is added
12:47:09 <oomichi> sdague: do we have a nova-spec for that now?
12:47:18 <johnthetubaguy> but honestly, I consider that all a bit evil, but its a heads up
12:47:29 <johnthetubaguy> repose that is
12:47:30 <sdague> oomichi: no nova-spec, we're going to use the openstack spec + nova blueprint
12:47:44 <oomichi> sdague: ah, I see.
12:47:55 <oomichi> sdague: nice combination
12:47:56 <johnthetubaguy> yeah, cross project consistency FTW
12:48:20 <alex_xu> cool, if no more question, looks it's time to move on
12:48:26 <sdague> sounds good
12:48:34 <alex_xu> #topic API futures - specs
12:48:47 <alex_xu> anyone people want to bring up?
12:49:11 <johnthetubaguy> did you all see the spec etherpad?
12:49:21 <johnthetubaguy> #link https://etherpad.openstack.org/p/mitaka-nova-spec-review-tracking
12:49:25 <johnthetubaguy> there is an API section in there
12:49:26 <alex_xu> johnthetubaguy: yea
12:49:43 <alex_xu> ok let me bring up one
12:49:43 <johnthetubaguy> feel free to use that in ways you all find useful
12:49:53 <gmann_> johnthetubaguy, cool
12:49:54 <alex_xu> johnthetubaguy: ok
12:49:57 <alex_xu> #link #link https://review.openstack.org/#/c/227274/1
12:50:04 <alex_xu> This spec is going to correct a lot of status code. Like 200->204, 200->201 and 200->202
12:50:06 <oomichi> johnthetubaguy: oh, thanks
12:50:11 <alex_xu> The question do we welcome this kind of change? I feel only 200->202 useful.
12:50:18 <alex_xu> other fix is more about consistent
12:50:32 <alex_xu> if we think the fix is ok, And do we think it is ok fix them all in one microversion?
12:50:40 <oomichi> alex_xu: that is based on api-wg guideline?
12:50:48 <alex_xu> oomichi: yea
12:50:57 <oomichi> alex_xu: cool :)
12:51:14 <gmann_> alex_xu, if changing all then this seems huge change so increase in x?
12:51:20 <gmann_> for x.y
12:51:32 <sdague> I feel like we should bring all the API wg changes in in one microversion
12:51:43 <alex_xu> gmann_: yea, one microversion change a lot of apis
12:51:44 <sdague> and it should include the new header as well
12:51:52 <gmann_> sdague, +1 that will be great
12:51:56 <johnthetubaguy> sdague: its tempting
12:52:19 <johnthetubaguy> so the thing that worries me, is making it harder for existing users to use new features
12:52:22 <sdague> but, before we do that, we should make sure we've got reasonable way of showing documentation for microversions
12:52:26 <gmann_> johnthetubaguy, it avoids having lot of microversion for same kinda fix
12:52:31 <johnthetubaguy> any its very marginal benifit
12:52:39 <sdague> johnthetubaguy: right, I don't think it's a huge rush
12:52:44 <johnthetubaguy> sdague: yeah, actually thats a very good way of look at it
12:52:52 <sdague> lets make sure we have a docs before / after story that looks good first
12:53:06 <johnthetubaguy> so I think its something we should push until next cycle
12:53:18 <sdague> johnthetubaguy: yeh, I'm fine with that
12:53:19 <johnthetubaguy> what do you all think?
12:53:31 <sdague> or late this cycle if the doc display is all sorted
12:53:43 <alex_xu> sounds ok for me
12:53:44 <sdague> but doing it before then is going to mostly create confusion
12:53:57 <gmann_> sounds good after doc thing
12:54:29 <gmann_> sdague, johnthetubaguy anytime we gong to change x in microversion?
12:54:45 <sdague> gmann_: I don't think so
12:55:03 * alex_xu mis-reading gmann_ works in previous
12:55:05 <sdague> I never believed X was meant to be changed
12:55:14 <gmann_> because we have not shorted out the y arting point of any x
12:55:17 <alex_xu> yea
12:55:19 <johnthetubaguy> yeah, I don't think we defined what that would mean
12:55:24 <sdague> it will be 2.y forever
12:55:24 <gmann_> arting -> starting
12:55:32 <johnthetubaguy> sdague: +1
12:55:33 <gmann_> yea, my feeling too
12:55:38 <oomichi> sdague: yeah, that is
12:55:56 <sdague> people kept confusing this for semver :) it's not, it's negotiation.
12:56:21 <oomichi> sdague: that is common misunderstand on current microversion anyway
12:56:22 <alex_xu> another one
12:56:24 <gmann_> :)
12:56:30 <johnthetubaguy> right, its a different concept
12:56:31 <alex_xu> #link https://review.openstack.org/#/c/209917/
12:56:54 <alex_xu> it's add project_id and user_id to server-group response
12:57:04 <gmann_> alex_xu, ahh
12:57:12 <alex_xu> the only think I don't like is only show project_id and user_id when admin context is used
12:57:23 <alex_xu> I think we should just show those two attrs in all the times
12:57:32 <alex_xu> and everything is simple
12:57:38 <johnthetubaguy> +1
12:57:39 <alex_xu> what would you think guys?
12:57:54 <gmann_> will it be more useful in create response /
12:57:55 <Kevin_Zheng> it will make no harm I guess
12:58:02 <johnthetubaguy> do we show user_id for server, I can't remember now?
12:58:02 <oomichi> alex_xu: +1
12:58:25 <gmann_> in create we do not show
12:58:30 <edleafe> alex_xu: +1
12:58:37 <alex_xu> johnthetubaguy, I remember yes, at least nothing just for admin user
12:58:37 <oomichi> alex_xu: nice to make consistent API and there is not demerit for doing that I guess
12:58:41 <sdague> alex_xu: yeh, showing it all the time seems the right call
12:58:57 <alex_xu> ok, cool, thanks guys for having agreement
12:59:09 <alex_xu> so I have enough more today
12:59:14 <Kevin_Zheng> cool
12:59:22 <alex_xu> oops, I have nothing more today
12:59:26 <sdague> :)
12:59:29 <annegentle> I had a question
12:59:29 <ccarmack> alex_xu:  there was some talk of getting more people involved in API doc work.   I'd like to get involved.
12:59:29 <johnthetubaguy> cool, almost out of time
12:59:31 <annegentle> sorry I'm laste
12:59:32 <annegentle> late
12:59:38 <alex_xu> annegentle: :)
12:59:39 <annegentle> yeah ccarmack!
12:59:42 <alex_xu> #topic open
12:59:44 <sdague> ccarmack: awesome
12:59:51 <sdague> annegentle: what's up?
12:59:55 <alex_xu> ccarmack: cool
13:00:08 <ccarmack> annegentle, sdague:  I could do PoC or spec implemenation
13:00:13 <annegentle> alex_xu: any way to use the verbage from the existing api doc? I put that in my review and hadn't gone back to see your response yet
13:00:19 <alex_xu> sorry, annegentle ccarmack, it's time to close the meeting :(
13:00:34 <ccarmack> can we discuss on -nova?
13:00:34 <johnthetubaguy> lets jump into #openstack-nova quickly
13:00:35 <sdague> ok, let's go to #openstack-nova for follow ups
13:00:36 <annegentle> sure
13:00:37 <sdague> yes
13:00:44 <alex_xu> #endmeeting