12:00:02 <alex_xu> #startmeeting nova api
12:00:03 <openstack> Meeting started Tue Oct 13 12:00:02 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:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:07 <openstack> The meeting name has been set to 'nova_api'
12:00:12 <alex_xu> who is here today?
12:00:13 <edleafe> o/
12:00:20 <gmann_> hi
12:00:23 <Kevin_Zheng> hi
12:00:51 <alex_xu> hello everyone, long time no see~
12:01:07 <gmann_> yea :)
12:01:18 <johnthetubaguy> hello
12:01:21 <gmann_> alex_xu: hows was ur vacation ?
12:01:30 <sdague> o/ ( though I'm going to be in and out dealing with this fix and baby getting up)
12:01:34 <alex_xu> gmann_: it's great thanks
12:01:43 <alex_xu> sdague: it's fine
12:01:47 <alex_xu> so let's get start the meeting
12:01:56 <alex_xu> #topic actions from last meeting
12:02:06 <alex_xu> action: alex_xu catch up stable-core review the api bug kilo back-port
12:02:15 <alex_xu> that is done, the patches already merged
12:02:22 <alex_xu> #link https://review.openstack.org/227135
12:02:26 <alex_xu> #link https://review.openstack.org/227176
12:02:31 <alex_xu> action: alex_xu check to see if all the issues fixed on the v2.1 api doc
12:02:38 <alex_xu> Looks still have something didn't fix yet
12:02:46 <alex_xu> #link https://etherpad.openstack.org/p/nova-v2.1-api-doc
12:03:11 <alex_xu> so I will file bug for them, and decribe how we fix them
12:03:33 <alex_xu> Few of them need update our api sample, like we said all the extension must enabled. But some api sample file only show part of attributes, not include the extended attrs.
12:03:51 * bauzas waves not so late
12:03:52 <johnthetubaguy> OK, can we get nova folks working on those bug fixes, they seem really important
12:04:22 <alex_xu> yea, appreciate people can help on it
12:04:23 <gmann_> alex_xu: yea, all extension thing we decided
12:04:30 <johnthetubaguy> yeah, enabling all the extensions in the tests is a good one to start with
12:04:56 <alex_xu> after I file bug, I will link the bug back to the etherpad
12:05:02 <gmann_> alex_xu: johnthetubaguy : can we merge sample tests for all extension of should wait till we completely remove the extension things ?
12:05:13 <alex_xu> or anyone interesting on each item you can file the bug also
12:05:29 <johnthetubaguy> for the tests, we could just create a blueprint to track the effort?
12:05:33 <johnthetubaguy> if thats easier
12:05:34 <alex_xu> gmann_: we needn't wait to remove extension I think
12:05:44 <gmann_> alex_xu: johnthetubaguy ok
12:05:45 <johnthetubaguy> alex_xu: +1
12:06:00 <johnthetubaguy> now it does change our test coverage
12:06:02 <gmann_> i will do it, just create BP and on etherpad people can join
12:06:04 * edleafe has to run out for a few minutes
12:06:12 <johnthetubaguy> but it concentrates in on the default configuration, so I feel happier with that
12:06:20 <alex_xu> johnthetubaguy: for fix the wadl doc, we just need change few api sample I think, so we can quick fix them
12:06:28 <alex_xu> later we will run all the extension for all the api sample test
12:06:46 <alex_xu> gmann_: thanks
12:06:47 <gmann_> alex_xu: +1
12:07:01 <johnthetubaguy> I was thinking about us needing them for the swagger stuff I guess
12:07:08 <johnthetubaguy> but I am getting ahead of things
12:07:25 <gmann_> fixed one today - https://review.openstack.org/#/c/234072/
12:07:25 <alex_xu> #action gmann_ will creae BP and etherpad to track the work merge api sample test and run all the extensions
12:07:37 <alex_xu> johnthetubaguy: yes
12:07:44 <alex_xu> we will talk that later
12:07:46 <gmann_> which is something i want to discuss, actually this is one where v2.1 and v2 differ
12:08:00 <johnthetubaguy> gmann_: point me at the BP, and I can get it approved, etc
12:08:07 <alex_xu> anymore people sign up for fix wadl doc?
12:08:12 <gmann_> should we mention this diff on doc and have both response there?
12:08:16 <gmann_> johnthetubaguy: sure
12:08:18 <Kevin_Zheng> I can help
12:08:26 <alex_xu> Kevin_Zheng: cool, thanks!
12:08:31 <johnthetubaguy> awesome!
12:08:57 <gmann_> because this is the only case where response differ.
12:09:13 <alex_xu> #action alex_xu file bug for wadl doc problem, and work with Kevin_Zheng on fix them
12:09:26 <gmann_> or how about adding some comments there about v2 return net-id also
12:09:51 <johnthetubaguy> gmann_: for the ones that differ, I guess we added most of the stuff in a later microversion, or something like that?
12:09:51 <alex_xu> gmann_: emm...ok that need more thinking
12:09:57 <gmann_> alex_xu: consider me also for wadl if needed
12:10:06 <alex_xu> gmann_: thanks
12:10:14 <gmann_> johnthetubaguy: yea 2.12 has that attribute
12:10:35 <johnthetubaguy> gmann_: I think thats OK then, v2.11 and v2.0 can share, for that API call, maybe?
12:10:51 <johnthetubaguy> gmann_: if not, we will just need two separate tests, which is fine
12:11:31 <gmann_> johnthetubaguy: yea, test wise ok, i was thinking on doc - https://review.openstack.org/#/c/234072/
12:11:40 <johnthetubaguy> gmann_: ah, gotcha
12:12:09 <alex_xu> I thnk we can discussion each work item later, we have a lot of items today
12:12:21 <johnthetubaguy> yeah, +1
12:12:21 <gmann_> alex_xu: yea sure.
12:12:24 <eliqiao> +1
12:12:35 <alex_xu> action: nova-api team review and land outstanding doc patches for next week - https://review.openstack.org/#/c/230186 https://review.openstack.org/#/c/226253 https://review.openstack.org/#/c/229546/
12:12:43 <alex_xu> only https://review.openstack.org/#/c/230186 didn't merged yet.
12:13:00 <alex_xu> so hope all team member continue help on the review
12:13:04 <alex_xu> that looks like close
12:13:16 <alex_xu> action: sdague to add concept guide progress to standing agenda
12:13:26 <alex_xu> sdague: are you around?
12:13:33 <sdague> yeh, I don't think I made the agenda changes
12:14:00 <alex_xu> ok, anyway I added that in the agenda...
12:14:02 <alex_xu> action: sdague to propose API slot for summit
12:14:11 <sdague> alex_xu: I did that one
12:14:35 <alex_xu> do we have list for what we will discussion on the summit?
12:14:58 <alex_xu> or we should create one?
12:15:00 <johnthetubaguy> its on an etherpad
12:15:11 <johnthetubaguy> oh, sorry, not for the API session yet
12:15:29 <johnthetubaguy> the session was accepted, but not got the detail for that session locked down yet
12:15:39 <sdague> I had a brief list in the session submission
12:15:47 <alex_xu> sdague: cool
12:15:54 <sdague> johnthetubaguy: did that make it to the etherpad as well?
12:15:56 <alex_xu> johnthetubaguy: where we should wrote down the detail?
12:16:09 <johnthetubaguy> so I haven't created the official etherpads yet
12:16:37 <johnthetubaguy> wanted to wait till we had the scheduled nailed down, got an outstanding issue right now
12:16:55 <johnthetubaguy> so basically, we can decide where to put it, for now
12:16:55 <alex_xu> how about we have temp one, then people can review the list and wrote down the item they want to discussion?
12:17:01 <johnthetubaguy> yeah, +1
12:17:21 <alex_xu> then we can discuss the list in next meeting
12:17:23 <johnthetubaguy> I can try create them all this afternoon, that should help stop us having two etherpads I guess
12:17:36 <alex_xu> johnthetubaguy: cool
12:17:57 <alex_xu> johnthetubaguy: so we just waiting for you? or create temp one?
12:18:31 <johnthetubaguy> alex_xu: I don't mind, I will create the official one this afternoon
12:18:39 <johnthetubaguy> probably worth just waiting
12:18:45 <alex_xu> johnthetubaguy: ok, we just waiting
12:19:03 <johnthetubaguy> #action johnthetubaguy to sort out etherpads for API session, and send link to alex_xu
12:19:12 <alex_xu> johnthetubaguy: thanks
12:19:32 <alex_xu> #action nova api team review the api session list, and free to add item, and discuss that in next meeting
12:19:47 <alex_xu> so let's move one
12:19:52 <alex_xu> s/one/on/...
12:20:03 <alex_xu> #topic API Documentation
12:20:11 <alex_xu> API Concept Doc
12:20:30 <alex_xu> #link https://review.openstack.org/#/c/226253
12:20:41 <alex_xu> this one already merged, so we want to track the TODO?
12:21:47 <alex_xu> emm...no response
12:22:00 <johnthetubaguy> so ideally yes
12:22:05 <johnthetubaguy> maybe a blueprint for those too?
12:22:18 <johnthetubaguy> specless blueprint that is
12:22:21 <alex_xu> yea, blueprint also good
12:22:33 <johnthetubaguy> if you can create it, I can get that approved
12:22:40 <gmann_> yea and track all TODO there who all working ..
12:23:07 <alex_xu> ok, let me create one and create an etherpad track that.
12:23:25 <gmann_> +1
12:23:29 <johnthetubaguy> if we have good commit messages, attached to a single gerrit topic, it should be OK
12:23:40 <alex_xu> #action alex_xu create bp and etherpad to track the concept doc work
12:23:45 <sdague> we could just use a tag instead
12:23:49 <sdague> APIDoc
12:23:58 <sdague> or something that's searchable
12:24:05 <alex_xu> sdague: good idea
12:24:07 <sdague> or, honestly, we can search by file
12:24:29 <alex_xu> how about APIConceptDoc?
12:24:33 <johnthetubaguy> I just like the blueprint, because it raises the review priority automatically
12:24:49 <sdague> https://review.openstack.org/#/q/status:open+project:openstack/nova+file:%255Edoc/source/v2.*,n,z
12:24:54 <sdague> johnthetubaguy: ok
12:25:43 <alex_xu> cool, that mor eeasy
12:25:48 <alex_xu> s/mor/more
12:26:04 <alex_xu> ok, so let's move on
12:26:07 <alex_xu> Swagger Doc Generate
12:26:27 <alex_xu> I think there is probably two choice, one is generated from tempest which proposed by oomichi, another one is generated from nova code base. I worked out a PoC  of generated swagger from nova code base.
12:27:09 <alex_xu> I think this is good for us to compare which one better.
12:27:15 <johnthetubaguy> seems like it has to be in nova
12:27:15 <alex_xu> #link https://review.openstack.org/233446
12:27:34 <johnthetubaguy> I know that means moving those json response files, but thats fine
12:27:50 <alex_xu> yea, at least nova have more info
12:27:58 <gmann_> johnthetubaguy: yea, response file in Nova is really good
12:28:17 <sdague> alex_xu: can those be broken into more files?
12:28:18 <gmann_> currently those went in Tempest-lib along with other tempest service clients
12:28:46 <alex_xu> sdague: I think it can, at least move the json-schema into more files
12:29:01 <gmann_> sdague: alex_xu :may be ref of request and response file in swager file ?
12:29:15 <gmann_> and keep schema in separate
12:29:17 <alex_xu> gmann_: yea, something like that
12:29:30 <alex_xu> and the nova code base also need some change
12:29:32 <sdague> because I think if we had units the size of - x-get-2.10-2.12 that would be good
12:29:44 <sdague> files this large get a little lost
12:29:53 <gmann_> yea
12:29:58 <alex_xu> sdague: yea
12:30:00 <alex_xu> 1. The microversion should declare on the top of method. Which is used to iterate the supported version for an api, but current some microversions are coding deep into the code.
12:30:13 <alex_xu> 2. We haven't repsonse json-schema, which are in the tempest
12:30:26 <alex_xu> 3. 3. For no more extension, we need adjust our api samples test only run with all the extensions.
12:30:33 <sdague> yeh, but it's only in tempest because it didn't exist in the project
12:30:39 <alex_xu> gmann_: just take the last one
12:30:46 <sdague> if we bring that bit back it's fine
12:30:52 <johnthetubaguy> sdague: +1
12:31:00 <gmann_> yea
12:31:14 <gmann_> so we will do response validation option in nova?
12:31:32 <johnthetubaguy> we can add some functional tests for that, if we want
12:31:36 <gmann_> because tempest would not be able to do till those are given by Nova through some API etc
12:32:02 <gmann_> and remove validation from Tempest? and do in nova side only
12:32:02 <alex_xu> maybe just change the api-sample test to validate response?
12:32:20 <sdague> gmann_: I think the point is that tempest could consume them from nova
12:32:26 <sdague> instead of inventing them on it's own
12:32:27 <gmann_> sdague: yea
12:32:45 <sdague> so, one last thing, just because it's here
12:33:04 <sdague> "paths": {
12:33:05 <sdague> "/{project_id}/os-keypairs": {
12:33:23 <sdague> I started poking at what's required to actually get project_id out of our urls
12:33:50 <sdague> because it's in a really weird place where it's only there due to service catalog, but sometimes it's hardcoded because of that convention
12:34:20 <sdague> https://review.openstack.org/#/c/233079/
12:34:43 <sdague> we actually explode because of novaclient version negotiation
12:35:11 <sdague> but, the thing I wanted to bring up, is are folks on board with getting rid of project_id in urls?
12:35:30 <johnthetubaguy> so I think its a good idea, certainly getting it out of the service catalog
12:35:45 <gmann_> +1
12:35:52 <johnthetubaguy> it feels like is will need a microversion bump, etc
12:36:05 <sdague> yeh, I'm trying to figure out all the code that we're going to need for this
12:36:06 <alex_xu> johnthetubaguy: I also think about that
12:36:09 <edleafe> yes, I think that only swift has a serious issue with that
12:36:23 <johnthetubaguy> but for that service catalog standardisation, it would be great to remove the tenant first
12:36:25 <sdague> and, yes it will, but we kind of need to backport this as well
12:36:41 <johnthetubaguy> a backport?
12:36:47 <gmann_> cannot we do on base?
12:37:05 <sdague> the thing that I think needs backporting is project_id being optional in the url
12:37:10 <gmann_> and support both but ignore who all passing in url
12:37:21 <sdague> https://review.openstack.org/#/c/233076/
12:37:22 <johnthetubaguy> ah, backporting to v2.0 you mean?
12:37:24 <alex_xu> optional sounds ok
12:37:33 <sdague> and liberty
12:38:04 <sdague> so that there will be a microversion where you are 100% sure you don't need it
12:38:06 <johnthetubaguy> not sure we can backport that to liberty... but thats a separate debate
12:38:10 <sdague> yeh
12:38:23 <sdague> anyway, we'll have to talk this through
12:38:40 <sdague> the other thing we kind of need is https://review.openstack.org/#/c/233779/
12:38:46 <johnthetubaguy> yeah, I mean a project id of "key-pair" could be interesting
12:39:02 <sdague> because the endpoint you get from keystone is /v2.1/$id
12:39:09 <sdague> but if you GET that today it's a 404
12:39:18 <sdague> you have to know you have to strip the $id
12:39:27 <sdague> which is super gorpy
12:39:38 <johnthetubaguy> ouch, thats terrible, yeah
12:39:52 <sdague> that has odd implications for microversions
12:40:10 <johnthetubaguy> yeah
12:40:11 <sdague> maybe we can talk some of this through at summit, I'm trying to get enough code up to figure out all the rough edges
12:40:21 <alex_xu> +1
12:40:24 <johnthetubaguy> that would be a good thing to debate
12:40:32 <johnthetubaguy> once we have the options on the table
12:40:49 <johnthetubaguy> getting a sane service catalog seems like a good mitaka aim, alongside docs
12:40:58 <sdague> yeh
12:41:12 <alex_xu> so do we need bp and spec for generate swagger and remove project_id now? or after the summit discussion
12:41:30 <sdague> alex_xu: I think after the summit
12:41:40 <alex_xu> sdague: ok, cool
12:41:52 <johnthetubaguy> I am find with doing the swagger one now, if you want to get that advertised
12:42:04 <johnthetubaguy> so going back a step
12:42:06 <sdague> yeh, swagger is fine
12:42:11 <johnthetubaguy> do you have a link to the tempest based one
12:42:18 <johnthetubaguy> from oomichi
12:42:35 <alex_xu> johnthetubaguy: no, we haven't, oomichi didn't have chance wrote one yet
12:43:08 <johnthetubaguy> ah, so maybe thats a good thing
12:43:19 <johnthetubaguy> lets focus on moving stuff into Nova, so it can live in nova
12:44:02 <alex_xu> so let me continue update the poc making it show more thing, and I need talk with doc team, see how to match the ui with microversion extend
12:44:09 <johnthetubaguy> fwiw I think this is part of our transition away from assuming magic people will create all our docs for us
12:44:40 <johnthetubaguy> alex_xu: yeah, annegentle and someone I can't remember has the swagger prototypes we can link into I believe
12:44:51 <johnthetubaguy> with all the themes applied
12:45:05 <johnthetubaguy> so microversion wise, I think its a whole swagger tree for each version
12:45:23 <alex_xu> johnthetubaguy: yea, they have ui, and need nail down with them about how to extend swagger to support microversion
12:45:37 <johnthetubaguy> I thought that was kinda decided in some ways?
12:46:03 <johnthetubaguy> we have a different doc for v2.1 and v2.2... v2.12 etc
12:46:04 <alex_xu> johnthetubaguy: already decided? actually in that poc I put all the version  in the same file
12:46:30 <johnthetubaguy> ah, so I think we need to generate a doc for each version
12:46:35 <annegentle> alex_xu: hey I'm here
12:46:36 <alex_xu> johnthetubaguy: but I remember we said we can have drop list two select version for each api
12:46:43 <johnthetubaguy> and it references where it changed in the past, or something like that
12:46:52 <johnthetubaguy> alex_xu: yeah, thats what I am remembering too
12:47:02 <alex_xu> annegentle: hey, something you have interesting https://review.openstack.org/233446
12:47:16 <alex_xu> annegentle: and I think I need your help later
12:47:28 <gmann_> yea but in that case too we need separate doc which gets replaced like something on drop down list
12:47:40 <annegentle> alex_xu: yeah, drop list, something like this: https://libgit2.github.com/libgit2/#HEAD we talked about in Vancouver
12:48:29 <annegentle> alex_xu: oh, exciting
12:48:40 <alex_xu> ok, change the version, then change the whole doc to another version?
12:48:43 <annegentle> alex_xu: johnthetubaguy: russellsim can make a UI as we want
12:48:43 <alex_xu> annegentle: :)
12:48:56 <johnthetubaguy> yeah, I quite liked the highlighting here: https://libgit2.github.com/libgit2/#v0.15.0
12:49:01 <johnthetubaguy> that seems to work
12:49:18 <johnthetubaguy> https://libgit2.github.com/libgit2/#v0.15.0/group/indexer/git_indexer_free
12:49:20 <gmann_> +1
12:49:23 <johnthetubaguy> seems to link to all the versions
12:49:32 <johnthetubaguy> so yeah, lets do whatever makes that happen :)
12:49:34 <gmann_> in our case we can highlight the API got changed between versions
12:49:43 <annegentle> excellent
12:49:49 <gmann_> which gives very clear view
12:50:08 <annegentle> alex_xu: so you've decorated keypairs, do you imagine it'll take the release to decorate all calls?
12:50:12 <alex_xu> ok, if we generate swagger for each version, then probably needn't any extend for swagger spec
12:50:43 <annegentle> alex_xu: I think the only vendor extension we need is for POST actions
12:50:56 <johnthetubaguy> does anyone know what orange means here: https://libgit2.github.com/libgit2/#v0.21.3/group/commit/git_commit_create
12:51:00 <johnthetubaguy> green means add I guess
12:51:06 <johnthetubaguy> is orange change?
12:51:13 <alex_xu> annegentle: oops, sorry, I didn't get your mean
12:51:41 <sdague> johnthetubaguy: looks like
12:51:49 <sdague> it's a param add in at least one case
12:51:52 <alex_xu> annegentle: you mean we need doc all the calls? the code should work with the api without decorator first, then later we fill all the doc for all the api
12:52:03 <annegentle> alex_xu: ok
12:52:10 <alex_xu> looks like we will run out of time
12:52:14 <johnthetubaguy> sdague: yeah, I saw the id change,
12:52:20 <alex_xu> 10 mins left
12:52:44 <alex_xu> how about we talk that offline, let move on first
12:52:47 <johnthetubaguy> yeah, this is important, super happy to see progress on this
12:53:01 <annegentle> alex_xu: nice work
12:53:09 <alex_xu> annegentle: thanks
12:53:20 <alex_xu> so move on
12:53:27 <alex_xu> #topic API futures - specs
12:53:46 <alex_xu> #topic API futures - specs
12:53:53 <alex_xu> I have question, what kind of rule for which spec should bring up at here?
12:54:03 <alex_xu> sdague: do you have any suggestion ^?
12:54:34 <sdague> I think APIImpact tag is good to search on
12:54:41 <johnthetubaguy> +1
12:54:45 <alex_xu> so we want to go through all the spec at here?
12:55:00 <johnthetubaguy> more its a raise awareness
12:55:00 <alex_xu> currently we probably have 23 specs until yesterday
12:55:03 <johnthetubaguy> and cover sticking points
12:55:13 <alex_xu> ok
12:55:15 <johnthetubaguy> at least thats what I was thinking
12:55:38 <johnthetubaguy> so we should all go away and review those specs, ideally, and bring back any issues to next weeks meeting?
12:55:45 <johnthetubaguy> now thats probably two weeks work
12:56:00 <gmann_> +1
12:56:05 <alex_xu> ok, actually i prepare some, but we didn't have time
12:56:05 <sdague> yeh, it's tough with summit on the horizon
12:56:10 <johnthetubaguy> I have tried to catagorise specs here: https://etherpad.openstack.org/p/mitaka-nova-spec-review-tracking
12:56:22 <johnthetubaguy> yup
12:56:23 <alex_xu> just bring up this one https://review.openstack.org/#/c/180469/
12:56:29 <alex_xu> do we need microversion for it?
12:56:35 <alex_xu> This one change the overquota from 400 to 403, so I think it need Microversion right?
12:57:14 <johnthetubaguy> we should only do the new thing for folks requesting the new microversion, I guess, thats the question
12:57:28 <sdague> right
12:57:33 <sdague> that's the issue
12:57:42 <johnthetubaguy> I mean the user will have always expected both responses as possible
12:57:56 <johnthetubaguy> the problem is how does the user deal with the error code
12:58:08 <alex_xu> yea
12:58:08 <sdague> alex_xu: I think it should be a microversion. I still think 403 is the wrong call here. But apparently I lost that one with cdent
12:58:31 <johnthetubaguy> I don't like policy and quota having the same response myself, either
12:58:32 <alex_xu> sdague: ok
12:58:46 <sdague> but, honestly, I'd rather not adjust this one until we get the error spec out of API wg
12:58:50 <johnthetubaguy> but the alternatives seem to have been dissmissed
12:58:57 <sdague> because I think distinguishing it is important
12:59:02 <alex_xu> sdague: ok, that also sounds a plan
12:59:04 <johnthetubaguy> +1 I see this as dependent on the API WG
12:59:17 <alex_xu> ok 1 mins left
12:59:17 <jichen> ok, I will mark this as WIP
12:59:22 <alex_xu> #topic open
12:59:25 <alex_xu> jichen: thanks :)
12:59:45 <jichen> alex_xu: thanks for bring this out :)
12:59:54 <alex_xu> jichen: np
13:00:04 <alex_xu> so nothing more
13:00:08 <alex_xu> it's time to close
13:00:11 <alex_xu> thanks all!
13:00:15 <johnthetubaguy> alex_xu: thank you!
13:00:22 <alex_xu> #endmeeting