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