16:00:20 <etoews> #startmeeting api wg
16:00:27 <openstack> Meeting started Thu Jan 15 16:00:20 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:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:30 <openstack> The meeting name has been set to 'api_wg'
16:01:24 <etoews> i've been out sick the entire week with the flu. this is my first morning back so i haven't been able to keep up with the email or reviews or anything :(
16:01:38 <elmiko> =(
16:01:54 <sigmavirus24> That stinks
16:02:00 <sigmavirus24> Glad you're feeling better though
16:02:04 <elmiko> +1
16:02:09 <etoews> better-ish
16:02:11 <etoews> :)
16:02:18 <sigmavirus24> technicalities =P
16:02:23 <elmiko> lol
16:02:34 <etoews> #topic agenda
16:02:41 <etoews> #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
16:03:00 <sigmavirus24> Heh, not much there
16:03:16 <etoews> the standard.
16:03:26 <etoews> any new topics anyone wants to talk about to start?
16:03:56 <kaufer> Yes, I'd like to quickly discuss this review for "Add Sorting Guidelines": https://review.openstack.org/#/c/145579/
16:04:03 <sigmavirus24> kaufer: that's the one I wanted to discuss too :)
16:04:07 <kaufer> :)
16:04:09 <elmiko> nice
16:04:14 * sigmavirus24 was searching for it
16:05:10 <elmiko> i don't have a strong opinion on this one, i've been more following
16:05:41 <kaufer> I'm fine with changing the spec to reflect the alternative design that has been proposed (ie, sort=key1:desc,key2:asc,key:asc), but I'm worried that it will impact too many projects that have been using sort_key and sort_dir for some time
16:05:59 <etoews> kaufer: thanks for the analysis of the current design. i'm reading up on it now.
16:06:28 <kaufer> sure, for others, current design is here:  https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Sorting
16:07:48 <sigmavirus24> So the question I have is how much of this do we want to be friendly to new consumers and how much do we think legacy is important
16:08:22 <elmiko> this also kinda dovetails into the upgrade path ideas...
16:08:25 <sigmavirus24> The concern about impacting existing projects is being addressed on the mailing list as well (on a higher level)
16:08:33 <sigmavirus24> (See also what elmiko just ref'd)
16:08:57 <dtroyer> honestly I'm not nearly as concerned about legacy as having a solid way forward.  some existing projects will never change, some will
16:09:12 <sigmavirus24> ==dtroyer
16:09:13 <elmiko> would this be a good initial case to look at about how we could create a version upgrade guideline?
16:09:55 <sigmavirus24> elmiko: that's likely
16:10:07 <dtroyer> elmiko: I think that is totally separate, and an edge case for this group…it is policy and process as much as design
16:10:08 <sigmavirus24> This is also a case where we could support both versions simultaneously but make them exclusive
16:10:27 <sigmavirus24> (i.e. you can pick one style to use but both are available for a version)
16:10:36 <sigmavirus24> (But that's orthogonal to the discussion :))
16:10:50 <elmiko> dtroyer: that makes sense, i was just thinking in terms of us recommending something that will break legacy
16:11:11 <dtroyer> sure…but most of what we do here that isn't toally new will be that ;)
16:11:31 <elmiko> honestly, i'm for paving a way forward that is sensible. which may mean upsetting legacy code.
16:11:43 <sigmavirus24> I think most of us are in that camp
16:11:55 <dtroyer> yup
16:13:32 <sigmavirus24> kaufer: thoughts?
16:13:42 <kaufer> Ok, so then it sounds goal if this spec is to document the ideal, I will update it to reflect the new comma-separated sort parameter
16:14:16 <elmiko> kaufer: +1
16:14:17 <kaufer> And then projects that are implementing this in kilo (ie, nova) will switch to that during this release without a need to deprecate
16:14:30 <sigmavirus24> kaufer: sounds good to me
16:14:48 <sigmavirus24> Did I understand the CLI spec is choosing similar syntax?
16:15:17 <dtroyer> basically, yes
16:15:28 <sigmavirus24> I think this will mirror it well then
16:15:36 <kaufer> Yes, that got a lot of support in the cross project meeting, spec here:  https://review.openstack.org/#/c/145544
16:15:41 <sigmavirus24> Will be nice to have the API and the CLI reflect each other sort of
16:15:50 <sigmavirus24> Thanks for the link kaufer
16:16:01 <sigmavirus24> #link https://review.openstack.org/#/c/145579/
16:16:07 <sigmavirus24> #link https://review.openstack.org/#/c/145544
16:16:10 <sigmavirus24> (for reference later ;)
16:16:25 <sigmavirus24> Any other new topics?
16:16:28 <kaufer> thanks, I'm still learning the meeting shortcuts
16:16:36 <etoews> 1 sec...
16:16:40 <sigmavirus24> kaufer: I think #help will help you
16:17:13 <etoews> kaufer: once you update your proposal. it would be best to get a clear +1 from each of the api wg cross-project liasions for nova, neutron, cinder, and glance.
16:17:48 <sigmavirus24> That's a good idea kaufer
16:17:51 <kaufer> and Ironic
16:17:52 <sigmavirus24> s/kaufer/etoews/
16:18:08 <etoews> oops. ya. ironic too.
16:18:10 <kaufer> is there a list of those contacts?
16:18:19 <etoews> https://wiki.openstack.org/wiki/CrossProjectLiaisons#API_Working_Group
16:18:39 <kaufer> great, i'll add them as reviewers
16:18:47 <etoews> thx!
16:18:55 <kaufer> thanks for the feedback!
16:19:19 <etoews> since we'll be paving a way towards something more ideal. we'll need considerably more buy in from the projects.
16:20:27 <sigmavirus24> kaufer: thanks for bringing this up!
16:20:28 <etoews> #action kaufer to update https://review.openstack.org/#/c/145579/ and add relevent cross-project liaisons as reviewers
16:20:48 <etoews> #topic previous meeting action items
16:20:55 <etoews> #link http://eavesdrop.openstack.org/meetings/api_wg/2015/api_wg.2015-01-08-00.00.html
16:21:10 <sigmavirus24> etoews: and I covered all of our action items I think
16:21:21 <sigmavirus24> API Definitions discussion was started here: http://lists.openstack.org/pipermail/openstack-dev/2015-January/054153.html
16:21:27 <sigmavirus24> #link http://lists.openstack.org/pipermail/openstack-dev/2015-January/054153.html
16:21:41 <sigmavirus24> And the upgrade guidance discussion was started here:
16:21:43 <sigmavirus24> #link http://lists.openstack.org/pipermail/openstack-dev/2015-January/054511.html
16:22:05 <elmiko> i've got a basic barbican swagger doc created
16:22:11 <elmiko> it was a winding path though
16:22:13 <sigmavirus24> They both seem to have some positive feedback from the people who have taken the time to read them and respond
16:22:14 <elmiko> #link https://github.com/elmiko/os-swagger-docs
16:22:24 <etoews> nice!
16:22:29 <elmiko> that's where i'm collecting all my efforts
16:22:44 * sigmavirus24 looks at elmiko's repo
16:22:50 <elmiko> the real issue with pecan based apps is that the object-dispatch is difficult to analyse
16:22:53 <elmiko> so...
16:23:03 <elmiko> i created a pecan-swagger project with some basic decorators to help out
16:23:19 <elmiko> this meant i needed to make a barbican branch with the proper markup, but it worked
16:23:42 <elmiko> it produces the same minimally compliant swagger doc, but it's a start
16:24:06 <elmiko> if i go further with this i'll start looking into pulling more information from the code base(e.g. validation schemas)
16:24:14 <sigmavirus24> awesome!
16:24:35 <elmiko> #link https://github.com/elmiko/pecan-swagger
16:24:48 <elmiko> it's quite basic at the moment, but it's a start =)
16:25:05 <elmiko> i really need to generate some docs for that though
16:25:11 <sigmavirus24> :D
16:26:26 <elmiko> what are the range of wsgi frameworks that are in use across openstack?
16:26:33 <elmiko> is it just pecan and flask?
16:26:49 <sigmavirus24> some use wsgi directly I think
16:26:56 <sigmavirus24> I feel like there's another one or two too
16:27:07 <elmiko> webob?
16:27:35 <sigmavirus24> yes
16:27:55 <elmiko> oh, another point about the whole api specs issue. i see much talk about moving towards WSME, is this something we would want to investigate?
16:28:59 <sigmavirus24> I haven't looked too closely at WSME before
16:29:03 <sigmavirus24> Might be worth investigating
16:29:42 <elmiko> it looks cool, but really seems useful for doing things like defining the api in wsme then deriving other formats from that definition.
16:29:49 <elmiko> i really need to read more, but it looks interesting
16:30:00 <etoews> i'm not familiar either
16:30:08 <sigmavirus24> looks like a stackforge project
16:30:09 <elmiko> and i think there are a few projects using it, i wanna say glance and nova?
16:30:24 <sigmavirus24> The example also shows it has little intention of supporting Py3
16:30:34 <elmiko> well that's not good
16:30:39 <sigmavirus24> Yeah that's far from ideal
16:30:54 <elmiko> i just know from poking many people about swagger and wadl that wsme seems to come up often in those conversations
16:33:00 <elmiko> that's about it for my update =)
16:33:08 <etoews> thank you!
16:33:13 <etoews> #topic APIImpact
16:33:28 * sigmavirus24 needs to get better at going through those reviews tagged with this
16:33:28 <etoews> #link https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
16:34:16 <etoews> anything here anyone wants to point out?
16:34:23 <sigmavirus24> #link https://review.openstack.org/#/c/130715/
16:34:31 <sigmavirus24> That looks interesting (but I haven't read it closely yet)
16:35:52 <elmiko> yea, that does look interesting
16:35:56 <sigmavirus24> Seems to be mostly cribbing from Keystone
16:35:58 <miguelgrinberg> sigmavirus24: looks like something that can be made into a guideline doc
16:36:07 <sigmavirus24> miguelgrinberg: my thoughts as well
16:36:07 <elmiko> miguelgrinberg: +1
16:36:13 <miguelgrinberg> but I haven't read it either
16:36:18 <sigmavirus24> Do I sense an #action item for miguelgrinberg ?
16:36:19 <sigmavirus24> =P
16:36:31 <miguelgrinberg> ha! punishment for being late
16:36:38 <miguelgrinberg> I can take it, sure
16:36:43 <sigmavirus24> Well you practically volunteered =P
16:36:50 <etoews> "From the point of view of whole OpenStack projects, the ways are not consistent and application programers should write an application for handling these extensions by different ways. Now there is JSON-Home as one of standard ways and Keystone has already implemented this feature on Keystone REST API."
16:37:04 <etoews> sounds ripe for a guideline :)
16:37:09 <sigmavirus24> Yep!
16:37:14 <miguelgrinberg> +1
16:37:18 <sigmavirus24> #action miguelgrinberg to turn https://review.openstack.org/#/c/130715/ into a guideline
16:37:41 <sigmavirus24> sorrynotsorry
16:37:53 <miguelgrinberg> I'll find a way to pay you back
16:37:59 <etoews> another one caught my eye https://review.openstack.org/#/c/131094/
16:38:20 <etoews> but only because it used the word "status"
16:38:42 <sigmavirus24> miguelgrinberg: should be simple enough
16:38:58 <etoews> which reminded me of jaypipes email about it on openstack-dev.
16:39:21 <kaufer> I have another one, deals with getting the total count of resources during pagination queries:  https://review.openstack.org/#/c/134279/
16:39:48 <sigmavirus24> The full specification is here:
16:39:49 <sigmavirus24> #link http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/get-lock-status-of-instance.html
16:40:29 <kaufer> It is on my list to make this into a guideline, but was hoping for more feedback on the nova spec (which I probably won't get since the nova spec deadline has passed)
16:40:29 <miguelgrinberg> looks pretty minor, right? they just added a field to the representation
16:44:20 <etoews> #action etoews to do some analysis on the status vs state current design
16:44:59 <sigmavirus24> kaufer: that would be a good guideline since it was discussed on the ML
16:45:00 <sigmavirus24> Oh
16:45:14 <sigmavirus24> I have one more that I'd like to point out, give me a second to find it
16:45:36 <sigmavirus24> #link https://review.openstack.org/#/c/138051/
16:45:59 <sigmavirus24> Essentially bolting on ElasticSearch to glance for Horizon search improvements
16:46:17 <elmiko> another interesting one
16:46:57 <miguelgrinberg> sigmavirus24: POST request for a search?
16:47:09 <miguelgrinberg> do you know what not GET?
16:47:17 <miguelgrinberg> s/what/why/
16:47:28 <sigmavirus24> I don't know why. I must have missed that before the new year
16:47:43 <sigmavirus24> Most people don't realize you can send a request body with a GET I suppose
16:48:01 <sigmavirus24> (To be fair, it also isn't exactly common practice to do so)
16:48:09 <miguelgrinberg> I think all the stuff they put in the body can go as query string
16:48:09 <edleafe> Many tools only support request bodies with POST/PUT
16:48:24 <sigmavirus24> edleafe: you mean HTTP clients?
16:48:34 <edleafe> sigmavirus24: yeah
16:48:37 <miguelgrinberg> I would not use a body with GET, that's bound to give you problems, not all clients support that
16:48:44 <edleafe> I remember fighting a few of those over the years
16:48:50 <sigmavirus24> (Also RFC should really be redefined as Request for Compliance because no one cares if you comply or not)
16:49:01 <edleafe> sigmavirus24: :)
16:49:03 <sigmavirus24> miguelgrinberg: the only clients I care about do ;)
16:49:17 <miguelgrinberg> sigmavirus24: no idea which one you are talking about ;-)
16:49:21 <sigmavirus24> ones
16:49:23 <sigmavirus24> plural sir
16:49:43 * sigmavirus24 has his hat in too many http clients
16:49:49 <etoews> time is running down...
16:49:51 <sigmavirus24> Yes
16:49:53 <etoews> #topic guidelines
16:50:00 <etoews> should i switch the order of the APIImpact and guidelines topics in the agenda? we haven't been giving enough time to our own reviews!
16:50:31 <sigmavirus24> Maybe
16:50:52 <etoews> or maybe we just need to move to those topics more quickly...
16:50:54 <etoews> #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
16:51:36 <sigmavirus24> etoews: might be a good idea
16:51:53 <sigmavirus24> etoews: might be good to have people pick out APIImpact reviews before the meeting
16:52:00 <etoews> ya
16:52:14 <elmiko> we might also consider scheduling a spec review day or something?
16:52:29 <sigmavirus24> #link https://review.openstack.org/133660
16:52:35 <sigmavirus24> ^ Should make it's way through
16:52:47 <sigmavirus24> It was rather unanimous consensus and it's waiting on a +W
16:53:13 <sigmavirus24> #link https://review.openstack.org/#/c/137490/
16:53:14 <sigmavirus24> ^ Too
16:54:13 <etoews> miguelgrinberg: i think you're medata guideline needs more nova eyes as they would be affected the most
16:54:38 <etoews> sigmavirus24: +1 to a review day
16:54:40 <miguelgrinberg> it would affect more the others, nova is the closest one
16:54:50 <sigmavirus24> etoews: that was elmiko ;)
16:55:08 <etoews> oops. +1 elmiko :)
16:55:16 <elmiko> it's all good =)
16:56:20 <miguelgrinberg> did you guys see the sorting cmd line guideline? they default to descending order, for an unknown reason
16:57:01 <sigmavirus24> miguelgrinberg: we discussed it
16:57:56 <elmiko> almost out of time
16:58:07 <sigmavirus24> ->| |<- close ;)
16:58:35 <elmiko> lol
16:58:48 <sigmavirus24> I have few opinions on defaults
17:00:10 <etoews> alright. i guess we need to call it there.
17:00:14 <etoews> #endmeeting