16:00:17 <etoews> #startmeeting api wg
16:00:18 <openstack> Meeting started Thu Dec  3 16:00:17 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:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:21 <openstack> The meeting name has been set to 'api_wg'
16:00:27 <elmiko> hi
16:00:36 <etoews> hihi
16:00:52 <salv-orlando> aloha!
16:01:01 <rosmaita> o/
16:01:07 <regXboi> moo
16:01:22 <rosmaita> we have a plethora of greetings
16:01:27 <elmiko> hehe
16:01:33 <lwilliams_> hi everyone!
16:01:45 <annegentle> o/
16:01:47 <gouthamr> 'lo!
16:01:48 <etoews> nice to see so many new nicks!
16:01:58 <elmiko> +1
16:02:03 <gmwolfgram> hi there
16:02:22 <etoews> #topic agenda
16:02:29 <etoews> #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
16:02:45 <etoews> pretty full agenda
16:03:19 <etoews> #topic previous meeting action items
16:03:31 <sdague> o/
16:03:46 <etoews> sounds like nothing happened in the prev meeting
16:03:55 <etoews> so the one prior #link http://eavesdrop.openstack.org/meetings/api_wg/2015/api_wg.2015-11-19-16.00.html
16:04:31 <etoews> where did elmiko go?
16:04:38 <elmiko> here
16:04:47 <cdent> o/
16:04:50 <elmiko> and yea, no one showed for last week's meeting
16:05:09 <elmiko> i think the only action item we had was for rosmaita
16:05:09 <sdague> us holidays and all
16:05:20 <elmiko> yup
16:05:31 <elmiko> but usually the 00:00 meeting is not well attended
16:05:43 <etoews> ya...
16:05:56 <salv-orlando> espcially for folks in and around GMT...
16:06:10 <rosmaita> so on my action item ...
16:06:27 <rosmaita> i reached out to jamie lennox who wrote the 'version' wiki page
16:06:31 <rosmaita> but haven't heard back
16:07:02 <rosmaita> the action item was to get the wiki page into a patch for the guidelines
16:07:04 <etoews> rosmaita: link us to that wiki page
16:07:24 * rosmaita looking
16:07:45 <rosmaita> #link https://wiki.openstack.org/wiki/VersionDiscovery
16:08:01 <rosmaita> it's really quite good
16:08:31 <etoews> getting a guideline around that would be great
16:08:49 <elmiko> i'm curious how does this overlap with json-home as well?
16:09:18 <etoews> rosmaita: beyond being the original author, what did you need to talk to jammielennox about it?
16:09:34 <etoews> (i notice he's in #openstack-sdks)
16:09:52 <rosmaita> etoews: nothing
16:10:09 <rosmaita> etoews: i offered to RST it with him as co-author
16:10:18 <etoews> ah
16:10:22 <rosmaita> just feels like plagiarism to submit it myself
16:10:58 <sdague> in looking at that, that's mostly just a capture of the current world, right?
16:11:05 <sdague> that looks like what nova already does
16:11:25 <rosmaita> sdague: i think so ... and glance, too
16:11:26 <sdague> I guess the media types are a little different
16:11:36 <sdague> this doesn't account for microversions
16:12:06 <annegentle> rosmaita: yeah, I get that. license-wise the wiki is creative commons so should be fine without attribution http://creativecommons.org/licenses/by/3.0/
16:12:19 * edleafe wanders in late...
16:12:21 <sdague> rosmaita: yeh, co-authored-by is fine
16:12:44 <rosmaita> ok, maybe i will just slap it together, then
16:13:12 <rosmaita> (i used to be a college professor, so I am kind of sensitive to plagiarism issues ...)
16:13:20 <etoews> thanks rosmaita
16:13:39 <rosmaita> np, will work on it in my "free" time
16:13:44 <elmiko> hehe
16:14:08 <etoews> rosmaita: if you think it might be helpful, an analysis of how it's currently done could be put into https://wiki.openstack.org/wiki/API_Working_Group/Current_Design
16:14:30 <elmiko> that would be cool
16:14:55 <etoews> is anyone available to do an analysis that will help rosmaita version discovery guideline?
16:15:47 <elmiko> i can help if no one else is available
16:16:09 <etoews> thanks elmiko
16:16:31 <etoews> #action rosmaita to start a guideline for version discovery
16:16:47 <etoews> #action elmiko to start analysis of current style of version discovery
16:16:58 <etoews> #topic Glance image import refactor spec, new revision up (patch set 7) (rosmaita)
16:17:29 <rosmaita> i don't want to take up too much time, this is just a request to please take a look
16:17:40 <rosmaita> i put some specific things to look for on an etherpad:
16:17:50 <rosmaita> #link https://etherpad.openstack.org/p/api-wg-glance-import-refactor
16:17:51 <etoews> #link https://review.openstack.org/#/c/232371/
16:17:58 <rosmaita> thanks!
16:18:12 <etoews> yep. good to highlight things.
16:18:19 <rosmaita> (done)
16:18:37 <etoews> looks like we already covered the version discovery topic...
16:18:48 <etoews> #topic adding software projects to the wg (elmiko)
16:18:53 <etoews> take it away elmiko
16:18:59 <elmiko> cool
16:19:11 <elmiko> so this is a topic that came up at summit
16:19:33 <elmiko> i'm curious about the possibility of expanding the purview of the api-wg slightly to include some software projects
16:19:54 <annegentle> elmiko: ++ I have one in mind :)
16:20:00 <elmiko> initially i thought we might generate some tools to help with the guidelines, but this may not be ideal
16:20:31 <elmiko> annegentle and i talked, very briefly, about things like fairy-slipper maybe falling under our umbrella
16:20:54 <elmiko> my thought was that by adding a few more "crunchy" items to the wg, we might help to add more spark to the excitement
16:21:03 <elmiko> and possibly build a larger footprint for the wg
16:21:27 <elmiko> as well as push forward some of the api related code tools
16:21:50 <elmiko> any have thoughts about this?
16:21:53 <annegentle> basically this group has the most knowledge for testing APIs, and the new framework should enable more tests/comparisons and tie-in to tempest for same requests/responses
16:22:04 <annegentle> so to me it's a natural fit for this group to have core status on that tool
16:22:08 <cdent> we got pretty excited about this at summit because we saw it was a good way to get engagement that effectively trojan horses the guidelines
16:22:14 <annegentle> or at least those who want to be core and do reviews
16:22:23 <annegentle> heh cdent on the trojan horse
16:22:52 <elmiko> the reality is that guidelines are fun and all, but we seem to slowing down in our progress
16:23:13 <elmiko> i think it would be cool to have more "steam" behind the group, and these projects might be a way to generate it
16:23:59 <elmiko> i've watched as the security project added tooling and it has really helped grow interest in that group. maybe it could work for us as well?
16:24:58 <elmiko> does anyone have objections to pursuing this path?
16:25:16 <elmiko> or is it improper for us to expand the groups intent?
16:25:54 <edleafe> elmiko: it seems perfectly valid
16:26:12 <elmiko> cool!
16:26:53 <annegentle> I also have the nova API subteam on board to work on it
16:27:21 <annegentle> so it seems like a great way to spark interest esp. from those working in this space working together
16:27:33 <etoews> i have no real objection to this
16:27:33 <etoews> but i'd be very hesitant to increase the scope of the api wg mission statement
16:27:33 <etoews> i see this as a "sidecar" effort to the api wg
16:28:13 <etoews> more concretely, i would want http://specs.openstack.org/openstack/api-wg/ to continue to be focused on guidelines.
16:28:28 <etoews> s/would/wouldn't/
16:28:38 <etoews> gah
16:28:50 <cdent> I don't think there's any need to expand the mission, thus the "trojan horse stuff"
16:28:57 <etoews> more concretely, i would want http://specs.openstack.org/openstack/api-wg/ to continue to be focused on guidelines.
16:29:13 <etoews> ya. how this plugs into the wg is cool with me.
16:29:28 <etoews> s/how/however/
16:29:52 <sdague> is fairy-slipper someone more official than a random github url ?
16:29:56 <elmiko> i can see the specs site remaining focused on the guidelines, but if we were able to create a more generic "landing page" for the wg, would you mind if we had code projects and guidelines there?
16:30:05 <annegentle> It is in a review to be added sdague
16:30:05 <sdague> it would be nice to roll that into openstack somewhere if we expect we're going to use it
16:30:33 <annegentle> #link https://review.openstack.org/#/c/245352/
16:30:44 <annegentle> sdague: the docs team can govern if needed but I'd prefer another placement.
16:30:49 <etoews> elmiko: would the wiki page suffice? https://wiki.openstack.org/wiki/API_Working_Group
16:30:56 <annegentle> sdague: it's interesting, the api-wg repo isn't in projects.yaml anywhere is it?
16:31:07 <elmiko> etoews: i think that would be cool to start with
16:31:15 <annegentle> sdague: it will be added to openstack as soon as we get the core ACLs
16:31:34 <sdague> annegentle: ok, just reviewed your change, needs an irc channel update
16:31:38 <sdague> then I can +2 it
16:31:44 <elmiko> etoews: i think it would be awesome if we could one day have something like https://security.openstack.org/ as a home too
16:32:05 <annegentle> sdague: thanks
16:32:30 <elmiko> obviously not that specific url, but you get the idea
16:32:37 <etoews> sure
16:33:23 <annegentle> elmiko: honestly though developer.openstack.org is what you want
16:33:29 <elmiko> so, i'll keep an eye on fairy-slipper's progress and propose something to the wiki page when it gets included. does that sound fair?
16:33:30 <cdent> as we brought up at the summit the main challenge with this stuff is bootstrapping: it is supposed to enable more folk but needs more folk for it to be so
16:33:35 <annegentle> elmiko: and contributing to fairy-slipper gets you there
16:33:39 <annegentle> elmiko: sounds good
16:34:23 <elmiko> annegentle: do you see the wg as having a section on dev.os.o?
16:34:23 <etoews> so i'm cool with this but just a heads up that i wouldn't have any bandwidth to put towards it in the foreseeable future.
16:34:47 <annegentle> elmiko: YES absolutely.
16:34:58 <elmiko> etoews: ack, i'm good with driving on this one for now
16:35:01 <annegentle> elmiko: guidelines/consistency are much desired by the target audience for that site
16:35:11 <annegentle> much, much desired
16:35:20 <elmiko> annegentle: ok, i'll take a look at contributing that site then. thanks
16:36:02 <etoews> elmiko: do you have a specific action to take as the next step?
16:36:13 <elmiko> hmm
16:36:18 <elmiko> yea
16:36:22 <sdague> people just have to remember this is a long game, the impacts are already trickling out. We've delayed a few nova api changes to make sure things like limit marker guideline are locked in, so it's consistent going forward
16:36:23 <annegentle> elmiko: it's the api-site repo
16:36:31 <annegentle> sdague: agreed
16:36:47 <elmiko> sdague: yea, i see this effort playing out over the M cycle from our side
16:37:15 <sdague> ok, what else is on the agenda?
16:37:23 <annegentle> elmiko: as a next action, please review and comment on this spec: https://review.openstack.org/#/c/246660/
16:37:23 <elmiko> #action elmiko to investigate adding content to developer.openstack.org and the wiki page
16:37:25 <annegentle> #link https://review.openstack.org/#/c/246660/
16:37:35 <etoews> elmiko: i don't think sdague is talking in terms of cycles. he's talking in terms of years.
16:37:51 <elmiko> hehe, oop, my bad
16:37:58 <elmiko> but ack, i get it
16:38:08 <sdague> etoews: yeh, but cycles are half years :)
16:38:15 <sdague> so they are same order of magnitude
16:38:21 <annegentle> yah
16:38:33 <etoews> #action elmiko to review and comment on this spec: https://review.openstack.org/#/c/246660/
16:38:41 <etoews> okay. time to move on.
16:38:43 <elmiko> when we talked at summit we proposed the idea of adding these projects as something that would take most of the M cycle for us to make action on
16:39:16 <etoews> elmiko: the next couple of topics have your name on them. did we cover them already?
16:39:31 <annegentle> elmiko: for sure, even that spec I linked to is targeted to M but may have more work to scope
16:39:36 <elmiko> example project is a different beast, i should probably just make a post to the ML about it
16:39:42 <annegentle> elmiko: so the spec narrows to m hopefully
16:39:57 <elmiko> i wanted to get some feedback before i spent crazy time on it, just in case it was a no-go from the start
16:40:09 <elmiko> annegentle: ack
16:40:39 <elmiko> etoews: as for the link guidelines, i just wanted to see what folks were thinking about the LDO vs HAL debate for the guidelines
16:40:41 <etoews> elmiko: so anything else you want to bring up as a topic right now?
16:40:51 <etoews> ah
16:40:53 <elmiko> etoews: no, i'm ok skipping it for now
16:41:00 <etoews> yes. that needs some discussion.
16:41:01 <elmiko> the example project, that is
16:41:17 <etoews> #topic link guideline
16:41:40 <elmiko> ok, so the pagination guideline has now been updated to follow LDO style, which is what the error guideline was using
16:41:46 <elmiko> but i think there is a wider discussion here
16:42:02 <etoews> #link https://review.openstack.org/#/c/190743/
16:42:17 <etoews> i just noticed the change back to LDO
16:42:43 <etoews> that's certainly the safe thing to do for now
16:42:52 <elmiko> i tried to get something going on the ML, but didn't get any responses
16:42:55 <elmiko> #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/080291.html
16:43:10 <cdent> elmiko: I think you hit the tday lull
16:43:16 <elmiko> yea, probably
16:43:17 <etoews> sorry i didn't get a chance to dig into HAL :(
16:43:18 <cdent> and how we're entering the xmas lull :(
16:43:38 <cdent> I've done some HAL in the past but haven't had a chance to review the related thread or spec
16:43:39 <elmiko> from what i could tell, HAL looks nice but i think only jaypipes was championing it
16:43:41 <cdent> (at least not recently)
16:44:00 * cdent rather likes HAL
16:44:12 <sdague> is anything using it?
16:44:12 <etoews> i do think a switch to something like HAL for linking should be a much more deliberate choice rather than throwing it piecemeal into guidelines.
16:44:13 <cdent> but I'm not sure it has mindshare™
16:44:15 <elmiko> also, if we recommend HAL it would represent a shift away from what is currently more widely used.
16:44:23 <elmiko> sdague: i don't think so...
16:44:24 <annegentle> when you look at a URL, how can you tell if it's hal or ldo? what are some patterns to look for?
16:44:31 <sdague> yeh, it doesn't seem worth the transition cost
16:44:44 <cdent> sdague++
16:44:48 <elmiko> sdague: i kinda agree
16:45:05 <etoews> annegentle: these links are within a json body of the response
16:45:10 <sdague> annegentle: it seems to be mostly just how the metadata is nested
16:45:24 <elmiko> annegentle: the LDO style are what we see mainly see in the current designs #link https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Links
16:45:34 <sdague> "links": [
16:45:34 <sdague> {
16:45:34 <sdague> "rel": "help",
16:45:34 <sdague> "href": "TODO(sdague): example href"
16:45:34 <sdague> } ]
16:45:45 <cdent> in my experience all the ways of representing links have proven to be much harder to use in practice than it seems like they should be
16:45:56 <sdague> vs.
16:45:58 <sdague> "_links": {
16:45:58 <sdague> "self": { "href": "/orders/124" },
16:45:58 <sdague> "basket": { "href": "/baskets/97213" },
16:45:58 <sdague> "customer": { "href": "/customers/12369" }
16:45:59 <sdague> },
16:46:07 <annegentle> ah ok
16:46:19 <cdent> that latter way is _so_ much easier to use if you are seeking a particular rel
16:46:21 <etoews> i think i know what topic sdague wants to discuss next :)
16:46:51 <sdague> so, honestly, we should just stick with what we have
16:46:59 <elmiko> it just seems like such a reverse direction to propose (using HAL)
16:47:03 <sdague> because people already probably have code to get out the keys they want
16:47:11 <elmiko> +1
16:47:13 <annegentle> yah
16:47:29 <sdague> etoews: I was just trying to find quick examples to clarify  :)
16:47:33 <etoews> well elmiko did the leg work to initiate a discussion on it.
16:47:51 <etoews> no discussion followed
16:48:04 <sdague> yeh, I think part of it was the entire conversation was in links
16:48:14 <sdague> it would be good in future to put examples into the email
16:48:26 <sdague> because I think most people didn't really know why any of it was relevant
16:48:30 <elmiko> sdague: good suggesstion
16:48:49 <etoews> sdague: that's fair. people don't click links.
16:48:57 <elmiko> imo, the next step will be to generate a guideline and hash this out in the review
16:49:15 <sdague> yeh, you have to communicate enough of the problem statement before clicking links, so they are interested enough to follow them
16:49:16 <annegentle> elmiko: it was a week I was off and disabled the lists :)
16:49:26 <elmiko> annegentle: a wise move ;)
16:49:26 <etoews> elmiko: iff there's someone to champion it
16:49:40 <elmiko> etoews: exactly...
16:49:54 <elmiko> sdague: yea, i need to level up my ML-fu
16:50:15 <etoews> anybody have a new topic they want to bring up?
16:50:47 <sdague> etoews: service catalog tng kickoff
16:50:59 <annegentle> tng=the next generation for any non-trekkies :)
16:51:10 <sdague> we're finally getting things rolling post summit
16:51:13 <etoews> #topic service catalog tng kickoff
16:51:25 <sdague> http://lists.openstack.org/pipermail/openstack-operators/2015-December/009061.html is a post out to operator list to get some feedback on one of the open questions
16:51:40 <sdague> that links to a wiki page, which links to a bunch of other resources, like our pile of etherpads
16:51:51 <sdague> but it seemed like a thing folks here may want to participate in
16:52:10 <sdague> weekly meetings kick off next week
16:52:29 <elmiko> sounds cool
16:52:34 <sdague> mostly fyi for folks here
16:52:41 * cdent wants to get in on that
16:52:53 <annegentle> cdent: come on over
16:53:07 <annegentle> elmiko: you too
16:53:21 <cdent> there was a fair bit in the summit session of people trying to do things to work around perceived problems in http that aren't really there
16:53:27 <cdent> so there's plenty of overlap
16:53:41 <sdague> yeh
16:54:19 <sdague> it seemed to be of interest to this group. We're running this more like an ephemeral working group right now, the intent is to do this thing (over a few cycles) then disband the effort
16:54:33 <sdague> having declared success
16:54:47 <sdague> but it's probably a 3 cycle effort to get there
16:55:25 <elmiko> the idea is to align about the commonalities and define some best practice, then there really isn't much more to be done?
16:55:46 <cdent> elmiko:  no, there are bugs
16:55:52 <elmiko> ah, ok
16:56:00 <cdent> at least it seemed that way in the summit session
16:56:14 <cdent> more like mental bugs than tech bugs
16:56:19 <elmiko> right
16:56:34 <etoews> ah. the source of all bugs.
16:56:37 <annegentle> education bugs
16:57:26 <etoews> #topic wrap up
16:57:50 <etoews> we're not going to have time to look at any guidelines but lots of action in the pagination and microservices ones so that's good
16:58:14 <etoews> sdague: will you have any time in the nearish future to start on the error code documentation effort for http://specs.openstack.org/openstack/api-wg/guidelines/errors.html
16:58:59 <sdague> etoews: I'll try to do it next week
16:59:20 <etoews> cool.
16:59:48 <etoews> thanks everyone!
16:59:59 <etoews> #endmeeting