16:01:46 #startmeeting api wg 16:01:46 Meeting started Thu Dec 4 16:01:46 2014 UTC and is due to finish in 60 minutes. The chair is etoews. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:47 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:50 The meeting name has been set to 'api_wg' 16:02:00 etoews: or we both have our tzdata wrong =P 16:02:14 ha. that would be an awesome coincidence. 16:02:45 I pinged others who I know would be interested 16:02:50 thx 16:02:54 I think this is too earl for cyeoh though 16:03:01 kashyap: should be here though 16:03:22 dstanek: and edleafe were at a prior meeting (or two) I think 16:03:23 i'm here =) 16:03:28 sigmavirus24, Are you sure you intend to ping me? 16:03:33 cyeoh miguelgrinberg: you 2 in for the api wg meeting? 16:03:35 meh for this meeting my phone calendar says 16utc and my mac's calendar 00utc 16:03:48 salv-orlando: we have alternating meeting times 16:03:57 kashyap: maybe? 16:04:17 i have this time down for today's meeting 16:04:23 sigmavirus24: yep I know. I was just moaning about my mac's calendar failing to understand that apparently 16:04:29 sigmavirus24, I mean, I may not be the right 'kashyap' Can you give some context :-) 16:04:30 salv-orlando: ah okay :) 16:04:46 alright. i think we got the tzdata right. 16:04:46 kashyap: API-WG meeting. Thought you were a Racker involved 16:04:46 sigmavirus24: hiya - did you need me? 16:04:54 #topic previous meeting action items 16:04:58 dstanek: API-WG meeting? Were you interested? 16:05:18 this will be a quick one if cyeoh and miguelgrinberg aren't available. 16:05:28 sigmavirus24, No, I'm not. 16:05:31 sigmavirus24: yessir 16:05:53 i know cyeoh has surgery scheduled but i wasn't sure if he was going to make it to this meeting or not. 16:05:57 etoews: I missed the previous meeting. Are the action items somewhere? 16:06:06 1 sec. 16:06:18 #link http://eavesdrop.openstack.org/meetings/api_wg/2014/api_wg.2014-11-27-00.01.html 16:06:24 i should have added that right away 16:06:26 thank you 16:07:08 etoews: I think miguelgrinberg mentioned his first action item yesterday in team standup. I think that's completed 16:07:09 oh and 16:07:10 #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda 16:07:15 sigmavirus24: were you thinking of me? 16:07:23 ycombinator_: that's very likely 16:07:25 sigmavirus24: I'm Shaunak Kashyap 16:07:29 Racker 16:07:29 * sigmavirus24 nods 16:07:37 Racker Extraordinaire ;) 16:07:57 sigmavirus24, ^ There you go. 16:08:23 i see miguelgrinberg commented on that review. cool. 16:08:26 Sorry for the confusion kashyap :D 16:08:42 etoews: I think the point was to help make the API design better and it was successful in that regard 16:08:58 (If I skimmed from Miguel's comments yesterday correctly) 16:09:01 that's pretty good to hear. :D 16:09:24 (He painted it as a API-WG success so I don't think he wants the credit) 16:09:31 let's move on then 16:09:38 #topic voting 16:09:47 #link https://review.openstack.org/#/c/131358/ 16:10:03 it merged! 16:10:38 the Meetings wiki page had the wrong time so i though i missed this. just updated it 16:10:58 good feedback and seems like the there's consensus it's a good starting point. 16:11:49 and looks like cyeoh used it to merge https://review.openstack.org/#/c/131358/ ! 16:12:13 oops. 16:12:16 same link 16:13:07 i'll have to check and see if https://review.openstack.org/#/c/133087/ meets the guidelines for mergeing 16:13:44 #action etoews to check and see if https://review.openstack.org/#/c/133087/ meets the guidelines for mergeing 16:14:12 #topic APIImpact 16:14:24 #link https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z 16:14:59 does anyone have a particular APIImpact they'd like to discuss today? 16:15:54 I would like the help of somebody from this wg for this spec: Consolidating neutrone extension into core 16:15:59 nothing from me 16:16:11 the link might be more helpful: https://review.openstack.org/136760 16:16:44 Basically there is a discussion going on what is an extension, what is an optional feature, and what should be the minimum set of mandatory features for the networking API 16:17:15 this has a lot of impact on future API evolution, as we want to move away from extensions towards versioning, more or less micro 16:17:49 jaypipes already gave his contribution, a few more eyes might be of great help 16:18:52 thanks in advance 16:18:59 salv-orlando: that a pretty good size. anything you want to point out specifically or just want more eyes in general? 16:20:21 salv-orlando: can you also link us to the neutron microversions spec? 16:20:27 etoews: mostly the discussion in the resrt api impact section 16:20:45 is it similar to nova microversions? https://review.openstack.org/#/c/127127/21/specs/kilo/approved/api-microversions.rst,unified 16:20:47 etoews: we have no spec for microversioning. It was decided it could not be on the kilo roadmap. 16:20:58 ah 16:21:30 we have an impending wsgi framework switch. That kinds of put a limit on the api related changes we want to do in this release 16:22:14 Sorry. Looks like my bouncer got bounced 16:23:00 #action all review https://review.openstack.org/136760 with a extra eye on REST API Impact section 16:24:36 i'd link to point out https://review.openstack.org/#/c/138059/ 16:25:28 it's interesting in that it's for the magnetodb project, which (i don't think) we put an APIImpact section in their spec tempate 16:25:51 must be catching on lol 16:26:06 so they found out about the api wg somewhere else and added the flag 16:26:14 elmiko: exactly. :) 16:26:19 Awesome! 16:26:20 that's cool 16:26:46 wow, pretty huge change they have there. 16:27:00 actually it was pointed out in pset1 with a reference to the ml thread 16:27:43 and it's not a integrated project and apparently there isn't an implementation yet according to https://wiki.openstack.org/wiki/MagnetoDB#Scope 16:28:24 so it's the kind of project where we could have a big impact 16:29:01 my question is, do we want to somehow focus on projects like this? 16:29:44 one concern is that it's not like we have a whole lot of guidelines to apply just yet though 16:30:23 i think it's a nice idea to help on these type of projects(non-integrated), but without strong guidelines it might be difficult 16:30:28 etoews: mauybe we don't but it's good they show up when querying by APIImpact 16:31:09 ya. that's my gut feeling right now too. 16:31:33 even without guidelines though, it would be good if someone could acknowledge the APIImpact request so that the teams know we are involved 16:31:34 we don't have guidelines but seeing their process could help point us at places where guidelines would have big (early) impact on projects. 16:31:34 but wouldn't it be cool if they had a schema like swagger and we could just review that? 16:31:55 etoews: +1 swagger ;) 16:31:56 that'd be neat 16:33:13 ryansb: agreed. i would like to somehow keep an eye on this so we can see where we can have that impact. 16:33:25 but i'm not totally sure how to go about that 16:33:29 what's the action item? 16:33:53 start a conversation with them on the ml? 16:34:00 see what come of it? 16:34:13 that sounds like a good start 16:34:18 probably "review as we would an integrated project, keep note of where guidelines would help" 16:34:25 or at the least start a conversation in the gerrit review 16:35:18 and also invite every project who adopts apiimpact to nominate a liaison maybe 16:35:29 salv-orlando: +1 16:35:47 i think i'd prefer to start on the ml and do a bit of an intro. we've never engaged a project like this before so go in nice and easy. 16:35:58 salv-orlando: +1 16:36:27 i'll take that as the action item 16:37:17 etoews: agreed about ml being a little more casual, at least until a project has a liason 16:37:40 #action etoews email the magnetodb team on the ml to intro the api wg, request a liaison, and kick off a discussion 16:38:00 let's move on 16:38:01 #topic guidelines 16:38:09 #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z 16:38:51 anybody care to point out a particular guideline? 16:39:12 yes, I'd like some help with https://review.openstack.org/133660 16:39:42 there's been a lot of good back and forth and +/-1s but I think it has reached a bit of a stalemate 16:40:10 so I could use some suggestions on how to make this move forward 16:41:05 ycombinator_: I'll look at it 16:41:38 ycombinator_: i haven't looked at this one yet, it's going to take me a few minutes to get up to speed 16:41:50 thank you folks 16:42:06 ycombinator_: did you grep through existing openstack code to see what's most in use? 16:42:59 etoews: not a grep through code but I looked at http://developer.openstack.org/api-ref.html 16:43:23 that's probably better. :) 16:43:36 or more sane for your sake 16:43:41 there's no clear winner - its about 50-50 - some representations use top-level keys; others don't 16:43:59 also, since these guidelines are supposed to be future-looking, should current state matter? 16:44:07 to some degree 16:44:32 especially since consistency is what we're striving for in a lot of cases. 16:45:17 did you mention your analysis in the review? 16:45:44 it was part of the patch originally (in the form of examples) but I will put in a comment 16:45:58 ycombinator_: is there a compelling reason for not always wrapping the returns to look like a list, even if a single value is returned? 16:46:38 question: if it's 50/50 then any guideline we set will be violated by half of the current APIs. Do you reckon it is ok to set a strict guideline in this case or should it be more relaxed? 16:46:50 ycombinator_: you could also put the analysis somewhere under https://wiki.openstack.org/wiki/API_Working_Group/API_Improvements if it doesn't fit nicely in a gerrit comment 16:48:06 salv-orlando: we're always going to get push back on "strict". i prefer that though because otherwise we'll never get the consistency that end user devs need. 16:48:36 elmiko: I hadn't considered that as an option - thinking about impact 16:49:21 ycombinator_: it would at least create consistency between the returns, i'm not sure if there's a wider negative impact though 16:49:30 elmiko ycombinator_: thinking about that impact too. 16:50:16 as a client dev, if i see an array, i'm going to assume that at (under some set of circumstances) multiple resources can be returned. 16:50:29 that makes sense 16:50:38 if we just use doc to say otherwise, it isn't very intuitive. 16:50:55 yeah, I tend to agree 16:51:01 the representation should be self-documenting as much as possible 16:51:05 yes 16:51:07 and this would kinda take it the other way 16:51:20 ok, so if the endpoint always returns a singular it shouldn't act like it can return multiples? 16:51:29 I think so 16:51:30 right 16:51:38 that's intuitive 16:52:07 sorry to be so late, having hardware issues this morning 16:52:18 hello miguelgrinberg! 16:52:22 miguelgrinberg: hi 16:52:45 ycombinator_: any action items on that review then? 16:53:22 yes, for me to go through the current APIs and document how many use top-level keys in their representations vs. not 16:53:36 I'll document it on the wiki and link to it from a review comment 16:53:55 #action ycombinator to go through the current APIs and document how many use top-level keys in their representations vs. not and document it on the wiki and link to it from a review comment 16:54:09 ty 16:54:28 moving on in last 5 min. 16:54:33 #topic open topics 16:54:54 miguelgrinberg: was there anything you wanted to bring up? 16:55:24 was gonna say, this one seems close to completion https://review.openstack.org/#/c/133087 16:55:42 i wanted to mention that we've been really struggling with the lack of any sort of schema for the service catalog 16:56:19 elmiko: i have an action item to see if our merging guidelines can be applied to that one. 16:56:21 :) 16:56:24 did you guys see the -1 on my proposal? I responded earlier today 16:56:28 etoews: nice 16:56:30 I hope you agree 16:56:45 miguelgrinberg: link? 16:57:08 https://review.openstack.org/#/c/131320/ 16:57:31 and also, happy to see that the nova spec was corrected with a much much better API design 16:59:21 Luckily salv-orlando is here too 16:59:43 ah good, salv-orlando let me know if I have a hope of convincing you 16:59:43 I think we've also discussed the creation of multiple resources to death 16:59:48 miguelgrinberg: i think the point under contention is covered in this guideline https://review.openstack.org/#/c/133087 17:00:09 we're pretty much at time. will have to carry on in openstack-dev or elsewhere. 17:00:14 thanks all! 17:00:19 miguelgrinberg: I'm sorry time is over ;) 17:00:33 #endmeeting