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