12:00:02 <alex_xu> #startmeeting nova api
12:00:03 <openstack> Meeting started Tue Nov 17 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:06 <openstack> The meeting name has been set to 'nova_api'
12:00:15 <alex_xu> who is here today?
12:00:18 <markus_z> o/
12:00:26 <alex_xu> markus_z: welcome
12:00:50 <jichen> o/
12:01:36 <alex_xu> emm...so quiet today
12:01:50 <alex_xu> let's wait few more mins if more people join in
12:01:53 <oomichi> hi
12:02:12 <markus_z> It's early for the US folks I guess
12:02:19 <Kevin_Zheng> ih
12:02:22 <Kevin_Zheng> hi
12:02:27 <alex_xu> yea, pretty early
12:02:35 <alex_xu> jichen: oomichi Kevin_Zheng hi
12:02:36 * johnthetubaguy is lurking
12:02:46 <alex_xu> ok, let's start the meeting
12:03:29 <alex_xu> I changed a little for agenda, it's only talk about priority items, for the low priority only bring up when there is something important update
12:03:44 <alex_xu> #topic actions from last meeting
12:03:50 <alex_xu> alex_xu update the PoC to show more example
12:03:58 <alex_xu> #link https://review.openstack.org/233446
12:04:22 <alex_xu> I have update it and with new way. it is use swagger spec in the nova code. And this way can instead of wsgi decorators.
12:04:46 <alex_xu> Then the doc and definition of api in single place(in swagger spec), that is more readable
12:04:57 <oomichi> alex_xu: thanks for doing that, nice direction for me
12:05:10 <alex_xu> appreciate people can take a look at and give feed back
12:05:14 <alex_xu> oomichi: thanks :)
12:05:36 <alex_xu> I will continue update and give more detail, still have a lot of TODOs
12:06:11 <oomichi> alex_xu: how about making the scope small as the first step?
12:06:16 <johnthetubaguy> alex_xu: can I check about the swagger?
12:06:30 <oomichi> alex_xu: it is difficult to do all thing at a single step
12:06:30 <johnthetubaguy> alex_xu: its auto generated, but then checked into our repo?
12:07:15 <johnthetubaguy> alex_xu: oh wait, I see you reference the external swagger doc for each API... hmm
12:07:20 <alex_xu> oomichi: I will separated the patch when most ideas figure out
12:07:36 <oomichi> alex_xu: I see, cool
12:08:11 <alex_xu> johnthetubaguy: sorry, I didn't quite get you, what means external swagger doc?
12:09:13 <oomichi> johnthetubaguy: yeah, right. on PoC, applying the swagger doc to the code instead of auto-generating swagger doc
12:09:22 <alex_xu> johnthetubaguy: you mean validated the generated swagger, or you mean how to read the swagger easily?
12:09:31 <oomichi> johnthetubaguy: from the code
12:09:56 <johnthetubaguy> yeah, I was kinda expecting the swagger to get auto generated from the code
12:10:25 <oomichi> johnthetubaguy: that is one way, and the other is to apply swagger doc/spec to the code
12:10:39 <alex_xu> johnthetubaguy: the PoC use swagger to describe the API directly
12:11:11 <alex_xu> instead of those wsgi decorator like wsgi.response(204), expected_errors((400, 403, 404)), ....
12:11:14 <johnthetubaguy> yeah, not sure thats what I was expecting
12:11:52 <oomichi> on http://swagger.io/getting-started/ , there are two ways to apply swagger
12:12:10 <alex_xu> johnthetubaguy: yea, it is another try, currently the python looks like more clear. and document and definition in the single place
12:12:11 <oomichi> on current PoC, that seems top-down approach
12:12:21 <johnthetubaguy> so, this feels very error prone, honestly
12:13:13 <oomichi> the first PoC is maybe johnthetubaguy expectation.
12:13:35 <oomichi> but the code was dirty due to a lot of decorators
12:14:08 <oomichi> on each api implementation
12:15:39 <alex_xu> there are some tools use similar way in the flask, like https://github.com/rochacbruno/flasgger
12:15:53 <alex_xu> the only different is they write swagger in the doc string
12:16:54 <oomichi> alex_xu: that seems big difference for nova's implementation ;)
12:17:20 <alex_xu> so anyway continue discussion on the gerrit, give people more time to think about it?
12:17:30 <johnthetubaguy> yeah, I think so
12:17:48 <oomichi> alex_xu: nice for doing that
12:17:49 <alex_xu> oomichi: yea, looks like we instead of some infra tools we build before
12:18:16 <alex_xu> so let's move on
12:18:32 <alex_xu> alex_xu contact the doc team about swagger stuff
12:18:32 <sdague> I agree with johnthetubaguy, this seems really error prone
12:19:14 <alex_xu> I didn't finish this action....so give another action I will do it in this week
12:19:22 <alex_xu> #action alex_xu contact the doc team about swagger stuff
12:19:33 <alex_xu> sdague: so you still like use doc string?
12:19:47 <sdague> yeh, at least that's near the code
12:20:03 <johnthetubaguy> honestly I preferred the decorators to hand creating the swagger
12:20:22 <johnthetubaguy> but doc string would be event better, I think
12:20:28 <sdague> honestly, the https://github.com/rochacbruno/flasgger stuff does look interesting. To the point that a N conversion of the wsgi stack to flask might be worth while
12:20:41 <alex_xu> sdague: actually we need create a format for doc string, that looks like we create another 'swagger' spec
12:21:09 <sdague> honestly, the yaml that flasgger uses looks like what I'd expect
12:21:37 <johnthetubaguy> sdague: using the same yaml as flasgger looks like a good idea
12:21:48 <alex_xu> sdague: but feel that is error prone, the decorator and doc string may talk about different thing
12:22:04 <sdague> alex_xu: but at least it's right there on the method
12:22:11 <oomichi> yeah, that is diferent from current implementation
12:22:27 <sdague> if these things are in another part of the tree, they are going to be wrong
12:22:38 <sdague> we saw that with the wadl
12:22:40 <johnthetubaguy> alex_xu: we can test they are in sync, and at least they are close to each other
12:22:50 <oomichi> it would be nice to do that after migrating to flask
12:22:53 <johnthetubaguy> yeah, I think wadl tought us we just ignore it
12:23:22 <alex_xu> johnthetubaguy: ok
12:23:26 <johnthetubaguy> although I would rather we didn't add flask into the mix here, unless we really need it
12:23:32 <sdague> yeh, that's fine
12:23:40 <oomichi> ok
12:23:41 <sdague> I think we can coopt their format though
12:24:32 <sdague> anyway, I think the experiments so far have kind of shown there are some hard issues to work through here, which means I think we should put this down for the rest of the cycle, otherwise we're going to be distracted by this and not touch the docs
12:25:33 <alex_xu> sdague: you mean focus on current wadl api reference/
12:25:59 <alex_xu> s/\//?/....
12:26:30 <sdague> no, I mean focus on the text of the API
12:26:47 <oomichi> sdague: that is concept thing?
12:26:53 <johnthetubaguy> I guess focus on the current wadl text and and the concept guide?
12:27:02 <sdague> honestly, the concept guide, examples in documentation on how to use the API are going to go much further for people than any formal specification
12:27:32 <johnthetubaguy> yeah, the concept guide is a big blocker
12:27:51 <johnthetubaguy> but the compete API reference not actually talking about some of the searching/filtering stuff, is a worry too
12:27:58 <sdague> sure
12:28:34 <alex_xu> the problem wadl isn't support microversion
12:28:56 <oomichi> can we get volunteers for making the concept guide better already ?
12:29:26 <johnthetubaguy> right, I think we should get v2.1 correct to start with
12:29:30 <jichen> yeah, current wadl some talked about latest version while some talked about v2.1
12:29:47 <alex_xu> jichen: oops, that is bad
12:29:54 <alex_xu> #link https://etherpad.openstack.org/p/nova-v2.1-api-doc
12:30:03 <johnthetubaguy> getting a solid v2.1, is the most important bit
12:30:04 <alex_xu> oomichi: ^ we use this track the work
12:30:09 <sdague> the only reason we use wadl is to generate this - http://developer.openstack.org/api-ref-compute-v2.1.html
12:30:10 <jichen> e.g http://developer.openstack.org/api-ref-compute-v2.1.html#keypairs-v2.1
12:30:20 <oomichi> alex_xu: thanks :)
12:30:21 <johnthetubaguy> sdague: yeah, I basically mean update that doc
12:30:25 <alex_xu> let me jump the topic
12:30:27 <sdague> however, we could just *edit* that html installed
12:30:29 <alex_xu> #topic API Documentation
12:30:30 <sdague> instead
12:30:42 <sdague> wadl was supposed to be a tool to make this easier, but it clearly isn't
12:30:47 * edleafe wanders in half-asleep
12:31:05 <sdague> so why don't we just take over the html file and just write it ourselves
12:31:39 <sdague> forcing through a set of tools that only make it harder to do what we want to do just seems weird
12:32:04 <alex_xu> looks like need some change for the doc job
12:33:21 <alex_xu> sdague: I guess the html theme is generated automactially
12:33:35 <sdague> sure, everything would need a change somewhere. But I mostly want to get folks to realize that these things are tools to make life easier, if they don't, we should go around them. We shouldn't be a slave to the tools.
12:33:40 <alex_xu> sdague: if there is something theme changed, that will be pain
12:34:30 <johnthetubaguy> so I do agree with should ditch bad tools, but I am not sure its all about the tooling at this point though
12:34:38 <sdague> johnthetubaguy: sure
12:34:52 <johnthetubaguy> we can get the base v2.1 sorted, with the existing tooling
12:34:56 <sdague> yep
12:35:03 <johnthetubaguy> and we can get the concept guide finished
12:35:17 <johnthetubaguy> at that point, we get to decide how to do v2.2 I think
12:35:23 <sdague> ok, so are there any content patches up for review now?
12:35:33 <johnthetubaguy> I just want to be sure we don't slow progress right now
12:35:42 <johnthetubaguy> so I added mine to the the etherpad
12:35:58 <johnthetubaguy> #link https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking
12:36:03 <sdague> link ? (sorry, so many etherpads)
12:36:36 <sdague> ok, great
12:36:57 <alex_xu> #info please put api doc patch into the https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking
12:37:15 <alex_xu> some patches link still in the https://etherpad.openstack.org/p/nova-v2.1-api-doc
12:37:26 <johnthetubaguy> so that is the main etherpad, that links to all others (in theory)
12:37:32 <jichen> alex_xu: which one? the patches in the doc etherpad?
12:37:32 <sdague> johnthetubaguy: yep, got it now
12:37:45 <jichen> ok, got it
12:38:48 <jichen> by the way, previous merged patches has not much review such as https://review.openstack.org/#/c/244038/
12:38:53 <alex_xu> ok, the finial decision is just focus on the concept doc and wadl api ref
12:39:03 <sdague> ok, so my recommendation. For this meeting. Agenda item #1: content patches up for review. Agenda item #2: most needed next content patches. Agenda item: #3 api specs outstanding by community. Agenda #4: api changes outstaing by community.
12:39:45 <oomichi> nice agenda :)
12:39:53 <jichen> +1
12:40:01 <johnthetubaguy> so one more question, the wadl stuff lives in openstack/api-site right now
12:40:02 <alex_xu> yea, nice agenda
12:40:23 <johnthetubaguy> do we want that inside nova? I am unsure really
12:40:38 <johnthetubaguy> sdague: +1 for that agenda, makes sense
12:41:11 <johnthetubaguy> so if its in nova, we can force people to land docs with their API patches, in theory, at least
12:41:22 <sdague> we can do depends-on
12:41:35 <oomichi> johnthetubaguy: it was difficult to change wadl files directly by hands
12:41:53 <alex_xu> johnthetubaguy: at least that is thing after wadl support microversion
12:42:01 <sdague> johnthetubaguy: I think the more important thing is to get the api subteam +2 rights on our repo
12:42:18 <sdague> johnthetubaguy: or some way that we can approve through content quicker
12:42:24 <sdague> so that we can sprint on those fixes
12:42:33 <alex_xu> yea
12:42:48 <sdague> ok, so here are some content patches which need review
12:42:50 <johnthetubaguy> sdague: so the etherpad is meant to do that, eventually the subteam approve counts as a +2, once its trusted
12:43:10 <sdague> #link https://review.openstack.org/#/c/236947/ - Add more 'actions' for server concepts doc
12:43:35 <sdague> johnthetubaguy: sure, that still means you are sitting around waiting for folks
12:43:59 <johnthetubaguy> sdague: we could do a feature branch for the docs
12:44:02 <sdague> if I dedicate 1/2 a day to reviewing through a bunch of this, I want the ability to land it all then.
12:44:14 <sdague> maybe we're talking across purposes here
12:44:20 <johnthetubaguy> possibly
12:44:25 <johnthetubaguy> do you mean api-site?
12:44:25 <sdague> my concern is api-site
12:44:27 <sdague> yes
12:44:28 <johnthetubaguy> ah, gotcha
12:44:43 <johnthetubaguy> maybe we could ask for a feature branch over there?
12:45:20 <johnthetubaguy> I mean we could just drag it into the Nova tree, along side the concept guide
12:45:32 <johnthetubaguy> but I see your point
12:45:35 <johnthetubaguy> thats not the key issue
12:45:35 <sdague> yeh, let's just ask about that
12:45:54 <sdague> #action sdague ask docs team about approval rights by api subteam on our wadl
12:46:00 <johnthetubaguy> sdague: thanks
12:46:03 <alex_xu> sdague: thanks
12:46:31 <alex_xu> so move on, we still have other agenda?
12:46:41 <markus_z> I'd like to say a few words about api related bugs, if we have time left?
12:47:18 <alex_xu> markus_z: yea, there is open topic
12:47:41 <alex_xu> sdague: do you want to talk remove project_id?
12:47:47 <alex_xu> if there is any update
12:47:51 <alex_xu> if not just jump it
12:48:02 <sdague> alex_xu: sure, auggy is working on tests for it right now
12:48:28 <sdague> she's going to get the api_samples to run a 4th run with optional project_id on v2.1
12:48:45 <sdague> we walked through the test infrastructure and the testscenarios the other day
12:48:47 <alex_xu> sdague: ok
12:48:57 <sdague> so I'm hopefully that's read to go this week
12:49:16 <sdague> I don't think it's passing quite yet
12:49:17 <alex_xu> sdague: ok, cool, just wait the patch up for review
12:49:29 <sdague> I'll add it to the etherpad once it is
12:49:39 <alex_xu> ok, let's mvoe on
12:49:42 * annegentle waves ever so briefly since kids have to get to school early today (only happens once a month)
12:49:45 <alex_xu> s/mvoe/move
12:49:50 <alex_xu> #topic API futures - specs
12:50:18 <alex_xu> one item from mriedem
12:50:20 <alex_xu> mriedem: There are a few nova specs that propose to add paging support to some APIs which are dependent onhttps://review.openstack.org/#/c/190743/ - so review on that as a priority would be helpful.
12:50:36 <alex_xu> I guess just a note for need review
12:51:10 <alex_xu> and I have no more at here
12:51:20 <johnthetubaguy> there was talk of pushing forward the API WG proposals
12:51:28 <alex_xu> johnthetubaguy: yea
12:51:30 <johnthetubaguy> tonyb suggested that, I think, on the ML
12:51:39 <johnthetubaguy> seems like some of that has come back to life
12:51:54 <alex_xu> johnthetubaguy: ok
12:51:57 <johnthetubaguy> it would be great if we could get general paging agreement before we add our own custom stuff
12:52:17 <sdague> yeh, I poked etoews about a couple of those, which is why this one and the error doc are moving forward
12:52:49 <sdague> I have a todo on the error doc as I strongly believed we want links to the docs for the errors to be mandatory
12:53:25 <alex_xu> ok, api-wg guideline is merged too slow, if something depend on that, it bad news
12:53:31 <alex_xu> let's jump to open
12:53:33 <alex_xu> #topic open
12:53:41 <alex_xu> markus_z: your turn
12:54:01 <markus_z> alex_xu: cool, thanks, I make it quick
12:54:07 <markus_z> It would be great if some volunteers could have a look at the api related untriaged bugs
12:54:11 <markus_z> #help https://bugs.launchpad.net/nova/+bugs?field.tag=api+&field.status%3Alist=NEW
12:54:20 <markus_z> If someone would step up to be the contact for such bugs in the future, please add your contact details in the wiki
12:54:26 <markus_z> #help https://wiki.openstack.org/wiki/Nova/BugTriage#Step_2:_Triage_Tagged_Bugs
12:54:52 <alex_xu> markus_z: thanks for reminder
12:55:10 <sdague> markus_z: yeh, good point. Honestly that's probably agend #5 for the meeting is untriaged bugs / and existing bugs
12:56:04 <alex_xu> any volunteers on triage api bug? if not, I will be the one
12:56:35 <sdague> yeh, I'll go through those right after this meeting
12:56:35 <jichen> I can help you on that
12:56:51 <alex_xu> jichen: thanks
12:56:54 <sdague> anyone else that's interested, we can chat about questions in #openstack-nova
12:57:00 <markus_z> awesome, thanks a lot!
12:57:12 <jichen> https://bugs.launchpad.net/nova/+bug/1516158  was opened by me , seems we don't have time to go through
12:57:12 <openstack> Launchpad bug 1516158 in OpenStack Compute (nova) "os-instance_usage_audit_log is used instead of os-instance-usage-audit-log" [Undecided,New] - Assigned to jichenjc (jichenjc)
12:57:44 <alex_xu> let me bring up this one quicly
12:57:47 <alex_xu> https://review.openstack.org/#/c/214691/
12:58:00 <sdague> alex_xu: yeh, I just approved it
12:58:03 <alex_xu> ^ I think we can remove those uselss retry header
12:58:07 <alex_xu> sdague: cool~
12:58:19 <jichen> sdague: alex_xu thanks~
12:58:20 <sdague> the retry header was really meant for API rate limit conditions
12:58:32 <sdague> I don't know why someone applied it to quota fails
12:58:45 <johnthetubaguy> makes sense, thanks
12:58:46 <alex_xu> yea
12:59:16 <alex_xu> 1 mins left, if no more question, let's move to openstack-nova
12:59:21 <sdague> yeh, thanks folks
12:59:27 <jichen> ok, thanks
12:59:28 <alex_xu> ok, thanks all
12:59:30 <edleafe> thanks!
12:59:37 <oomichi> thanks :)
12:59:38 <alex_xu> #endmeeting