16:00:43 #startmeeting api wg 16:00:44 Meeting started Thu Aug 27 16:00:43 2015 UTC and is due to finish in 60 minutes. The chair is etoews. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:45 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:47 The meeting name has been set to 'api_wg' 16:00:50 hi 16:00:57 o/ 16:00:59 hola 16:02:25 tidwellr: you mean talk about BGP in this channel now? 16:02:54 Juno: wrong timing. i think your people have moved to the neutron channel. 16:03:04 #topic agenda 16:03:11 #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda 16:03:26 etoews: what is the channel name? 16:03:53 i'm going to guess #openstack-neutron but i have no idea really 16:03:56 #topic previous meeting action items 16:04:40 #link http://eavesdrop.openstack.org/meetings/api_wg/2015/api_wg.2015-08-13-16.01.html 16:04:55 etoews: thanks 16:05:04 np 16:05:34 looks like there wasn't a meeting from last week so those action items are from 2 weeks ago. 16:05:36 well, i put up the etherpad, and started to fill it in. but not too much there yet 16:05:45 o/ 16:05:48 #link https://etherpad.openstack.org/p/mitaka-api-wg-session-plans 16:06:09 also, i will be in tokyo, so i can help moderate those sessions. assuming no collisions 16:06:19 awesome. thanks elmiko. 16:06:37 do we know if we'll have 2 sessions, or 1 big one, or? 16:08:04 are you asking cdent? 16:08:19 sorry 16:08:22 (or anyone else who will be at the summit for that matter) 16:08:23 was in a different window 16:08:31 yea, i guess so. i can't remember, did you request 2 sessions cdent ? 16:08:34 I signed us up on the spreadsheet for a single long session 16:08:39 ok, cool 16:08:59 i'll adjust the pad to be more agenda related then, instead of broken out by session 16:09:01 I wrote to the organizer to ask about whether we were supposed to split or could have more and got no response (this was the day after the last time I was at a meeting) 16:09:12 ah ok 16:09:26 the precedent on the spreadsheet was that people were doing a single block 16:09:28 also, i could probably use some help filling out the content for the session 16:09:48 elmiko: I'll try to help with that 16:09:50 etoews: not sure if you have any items we should address at the summit 16:09:53 cdent: thanks! 16:10:51 nothing in particular. a state of the union to kick things off would be good. 16:11:27 discussion on getting more people engaged. 16:11:43 that's a biggie 16:11:52 here's an important one, discussion on getting people to use the guidelines in reviews 16:12:32 cool, writing this down on the pad 16:12:42 yeah, being able to habitiually link to sections of the guidelines wil be handy 16:12:51 ultimately we want people to be reviewing based on the guidelines. -1 because you didn't follow guideline x [LINK]. +1 because you did. etc. 16:13:32 i noticed some interesting api related sessions in the sched on the main conf side of things. 16:13:42 #link https://www.openstack.org/summit/tokyo-2015/schedule/design-summit 16:13:51 #link https://mitakadesignsummit.sched.org/event/97bb02c6bbdfa5f5699b82ea1be2a810?iframe=no&w=&sidebar=yes&bg=no 16:14:01 #link https://mitakadesignsummit.sched.org/event/f4d9a391b6bdd09d6bcd9a5571fa2739?iframe=no&w=&sidebar=yes&bg=no 16:14:05 there's more too 16:15:42 the next topic is on Mitaka sessions but i guess we already covered that right elmiko? 16:15:57 yea, i think so 16:17:04 #topic guidelines 16:17:11 #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z 16:18:04 i want to replace that link with a link to our dashboard. it's almost ready. 16:18:14 sweet 16:18:18 nice 16:18:19 nice 16:18:24 it'll make things a bit more clear for where guidelines are at. 16:19:07 it's definitely not perfect and still needs eyes on it to make sure things don't slip through the cracks (w.r.t. what the dashboard query system is actually capable of) 16:19:26 i thought sdague was going to remove the dep. from https://review.openstack.org/#/c/189738/ , should we just repost it without the dep? 16:20:18 sorry, I lost track of that one 16:20:30 I honestly thought we'd get to resolution on the 501 issue well before now 16:20:31 no worries, i figured you had higher prio stuff =) 16:20:44 i wish we woud have... 16:21:06 sdague: i put the freeze on the 501 to move it forward. 16:21:19 so, given that it looks like the 501 one is schedule for merge next week, I'd just say we move forward assuming that will merge 16:21:26 we don't have unanimity but that's okay. 16:21:52 ok, fair 16:21:53 ya. at this point it's (hopefully) just a waiting game. 16:22:13 i just felt bad because the stuck one has been there since vancouver =( 16:23:07 yeh, that's fine. It's a slow march :) 16:23:13 cool 16:23:22 i'd like to highlight this process change about removing the voting restriction #link https://review.openstack.org/#/c/217764/ 16:23:47 elmiko: can you please move your +2 to +1 since it's not frozen yet? 16:23:48 i think it's a step in the right direction 16:24:19 yea definitely, sorry bout that. i was a little unsure about the process as opposed to guidelines 16:24:41 that's a fair point 16:25:38 it seems ok to me if we just stick to the rule that +2 is only for freeze. but process type stuff won't need a freeze, so we can just get some consensus then merge. does that sound fiar? 16:25:39 okay. forget what i said. :) 16:25:46 lol, too late ;P 16:25:52 ++ 16:26:12 so, gather a few more +1 then we can merge it 16:26:33 sure 16:26:57 there was some interest in versioning on the mailing list. 16:26:59 * ryansb +1'd 16:27:21 alex_xu: think you'll have some time to update your microversion guidelines? 16:28:09 i need to update #link https://review.openstack.org/#/c/167793/ 16:28:37 jaypipes: do you have some time to look at https://review.openstack.org/#/c/183599/ ? 16:29:35 has anyone seen Steven Kaufer around lately? 16:29:47 we need to figure out what to do with https://review.openstack.org/#/c/162716/ 16:30:36 i'm inclined to abandon it and proceed as i mentioned in my comment there. 16:30:42 +1 16:30:43 is there an amount of time, after which, it is not impolite to take over a review? 16:30:58 i'd say yes 16:31:17 so, like a month maybe? then it's fair to rewrite/update/etc 16:31:27 or is that too long 16:31:30 ya. that sounds about right to me. 16:31:33 cool 16:31:37 1 month seems legit 16:31:46 maybe we can unstuck some of these older guidelines 16:31:53 I imagine after a month the number of people that would complain would be quite low 16:31:54 if the submitter is around, ping first. 16:32:04 otherwise a month is more than enough 16:32:15 yea, don't want to be rude 16:32:22 +1 16:32:47 elmiko: speak for yourself, jerk 16:32:52 lol 16:32:56 cdent: haha 16:33:15 * cdent couldn't resist 16:33:33 fair, i nominate cdent as the api-wg rude-boy 16:33:43 \o/ 16:33:46 seconded 16:33:49 haha 16:34:16 annegentle was looking for feedback on https://review.openstack.org/#/c/214817/ 16:34:53 ooh, good point. meant to get back to that 16:36:38 ya. i've got a few comments to make there too. 16:37:01 any other guidelines people want to highlight? 16:38:41 nothing from me 16:39:00 #topic APIImpact 16:39:10 #link https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z 16:39:41 anything anyone wants to highlight here? 16:40:08 nothing specific but: it's pretty cool the number of them, people have caught on 16:40:28 +1 16:41:21 i see the Artifact Repository API specification has rumbled back to life. https://review.openstack.org/#/c/177397/ 16:42:13 yeah 16:42:24 that's a good way to put it 16:45:49 i'm looking at https://review.openstack.org/#/c/155931/4/specs/liberty/api-order-ssl-add-reissue-support.rst,unified and found http://specs.openstack.org/openstack/barbican-specs/specs/kilo/certificate-order-api.html that doesn't follow our metadata guideline 16:46:08 i expect it's already baked in but i'll comment anyway 16:47:10 any other topics people want to discuss? 16:47:27 the barbican folks have been really good about checking api-wg stuff recently. i think the kilo spec may have been before this time 16:48:36 I think I mentioned this last time, but wanted to say again: ceilometer is now gatting on a fully http api driven integration job that integrates ceilo, aodh, gnocchi, heat, and nova 16:48:40 (using gabbi) 16:48:50 nice 16:48:57 It is rather cool because it is so simple but powerful at the same time 16:49:12 and api-only seems like a good validation of how it is supposed to work 16:49:25 https://github.com/openstack/ceilometer/blob/master/ceilometer/tests/integration/gabbi/gabbits-live/autoscaling.yaml 16:49:52 and there are several other tests pending merge which add to that 16:50:01 it's easy to improve and all the usual good things 16:50:11 etoews: ugh, sorry, I will look at pushing a rev on that. sorry for the delay. 16:50:35 jaypipes: you should gander on that link I just posted if you have a moment 16:50:36 np. i'm probably the worst offender with my errors guideline. 16:53:05 cdent: have you had interest from any other projects in using gabbi? 16:53:25 besdies elmiko having some thoughts on it, no 16:53:33 I think that's partly a matter of PR 16:53:49 and all the usual too much to do that everyone experiences 16:53:55 yea, i'm trying to push for gabbi testing in our v2 api 16:54:09 not sure if it will get acceptance from the group though 16:54:34 elmiko: if that happens I'll be curious to hear why 16:54:57 i think mainly it could be due to our dependence on many other services. but we'll see 16:55:11 it's working so well in the various places I'm aware of it being used that I'd want to persuade 16:55:53 note that the link above is run from the command line, as part of a shell script, not a unittest harness 16:56:19 which provides some interesting ways to build up other services or gathering auth credentials or whatever before hand 16:56:48 well, when the time comes i will definitely drop you a line 16:57:10 cool, thanks 16:57:40 cool. if there's nothing else we can call it a couple of minutes early. 16:57:59 ✔ 16:58:10 #endmeeting