16:00:17 <etoews> #startmeeting api wg
16:00:18 <openstack> Meeting started Thu Mar 26 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:39 <elmiko> yo/
16:00:56 <miguelgrinberg> hi
16:00:57 <annegentle> hi
16:00:58 <etoews> \oy
16:01:02 <cdent> hi
16:01:04 <kaufer> hi
16:01:24 <stevelle> o/
16:01:29 <etoews> feels like long time no see :)
16:01:35 <elmiko> hehe
16:01:45 <dstanek> howdy
16:02:01 <etoews> #topic agenda
16:02:14 <etoews> #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
16:02:28 <sigmavirus24> o/
16:02:39 <etoews> i mixed it up a bit and moved the guidelines higher in the agenda
16:03:15 <etoews> seems like the past few  meetings (that i've been a part of anyway) have been about everything but the guidelines
16:03:43 <etoews> i'd like to get some guidelines in the bag
16:04:02 <etoews> but first...
16:04:02 <etoews> #topic previous meeting action items
16:04:13 <etoews> #link http://eavesdrop.openstack.org/meetings/api_wg/2015/api_wg.2015-03-12-16.00.html
16:04:58 <etoews> the only action there was for me to create a guideline about errors. and i've got a start on that.
16:05:14 <etoews> any other actions from meetings past that have fallen off the radar?
16:05:38 <miguelgrinberg> I had to start some discussion on metadata and tags on the ML, which I did a while ago
16:06:07 <etoews> what's the subject on that email? i don't recall seeing it.
16:06:19 <miguelgrinberg> let me look for it, it was more than a week ago
16:07:34 <miguelgrinberg> etoews: http://osdir.com/ml/openstack-dev/2015-03/msg00558.html
16:07:58 <annegentle> #link https://review.openstack.org/#/c/141229/ (Metadata guidelines)
16:08:21 <annegentle> #link https://review.openstack.org/#/c/155620/ (Tagging guidelines)
16:09:13 <etoews> sorry i missed that. my email filters were failing for a couple of weeks.
16:09:26 <sigmavirus24> etoews: I wouldn't possibly be able to guess why
16:09:27 <miguelgrinberg> but as you see, not much activity
16:10:03 <etoews> i starting to think we should add [all] to a lot of our [api] emails.
16:10:19 <etoews> people seem to be tuning out the [api]
16:10:45 <cdent> a) yes b) I suspect people have a hard time getting enough context on things like metadata and tagging guidelines to feel like it is relevant to them
16:11:18 <miguelgrinberg> yeah, b) makes sense, most people don't care
16:13:08 <etoews> hmmm...(b) is tough one.
16:13:54 <etoews> if nothing else, openstack requires a certain amount of perseverance and endurance.
16:14:02 <elmiko> it seemed like, aside from swift, there wasn't much pushback on the metadata ideas miguelgrinberg had put forth earlier
16:14:10 <annegentle> cdent: But the heat team did reach out to ask, so probably you could get some communication closure by circling back on the instance tag thread
16:14:31 <annegentle> (you meaning miguelgrinberg not you cdent, heh) :)
16:14:34 <miguelgrinberg> annegentle: not only that, they have implemented tags already :)
16:14:41 <annegentle> miguelgrinberg: figures
16:14:43 <cdent> :)
16:14:47 <annegentle> some of this is timing, with feature freeze looming
16:14:49 <miguelgrinberg> but I'm there pestering those guys all the time :)
16:14:56 <etoews> :)
16:14:58 <annegentle> "this" being split attention
16:15:34 <etoews> well we're talking about guidelines anyway so...
16:15:35 <etoews> #topic guidelines
16:15:46 <etoews> #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
16:16:03 <etoews> let's continue on #link https://review.openstack.org/#/c/141229/ for a bit
16:16:26 <etoews> is there consensus within the api wg on it?
16:16:51 <miguelgrinberg> I think the only critic was notmyname
16:16:58 <elmiko> yea, i like this solution
16:17:46 <etoews> alright. can people please put some +1's on it and see if we can get the ball rolling again?
16:18:04 <elmiko> will do
16:18:05 <miguelgrinberg> There were some comments from jaypipes that I answered, but he never confirmed he was okay with my reasoning
16:19:01 <miguelgrinberg> mostly related to the JSON structure, he thought it could be simplified
16:19:11 <etoews> i've observed there can be some long pauses between jaypipes responses :)
16:19:41 <sigmavirus24> Yeah it would seem like everyone else is fine with it
16:20:14 <sigmavirus24> notmyname wanted explicit character set definitions there (which the RFC deems is unnecessary and the I-JSON makes even more unnecessary)
16:20:19 <sigmavirus24> *the I-JSON RFC
16:20:39 <annegentle> sigmavirus24: I'd respond on the review with that so we all know. (I didn't know)
16:20:49 <sigmavirus24> annegentle: I responded earlier with that
16:20:50 <etoews> *is unfamiliar with i-json*
16:20:58 <annegentle> sigmavirus24: ah missed it in my scan, sorry
16:20:59 <sigmavirus24> etoews: it's new
16:21:02 <sigmavirus24> annegentle: no worries
16:21:19 <sigmavirus24> annegentle: notmyname then just asked for examples of foreign character sets being used in JSON
16:21:25 <sigmavirus24> I haven't looked to see if miguelgrinberg added that or not
16:21:37 <miguelgrinberg> Ah right, I did not
16:21:44 <sigmavirus24> (e.g., left-to-right character sets being able to be used in UTF-{8,16,32}
16:22:05 <etoews> miguelgrinberg: does it need an update before we start putting some of those +1s back?
16:22:06 <sigmavirus24> (Which if I remember my UTF-{8,16,32} well enough is also guaranteed)
16:22:24 <miguelgrinberg> I should at least make a note regarding all texts being UTF-8/16/32
16:22:49 <miguelgrinberg> I personally don't think it is necessary, but doesn't hurt to be explicitt
16:23:02 <etoews> #action miguelgrinberg to at least make a note regarding all texts being UTF-8/16/32 on https://review.openstack.org/#/c/141229/
16:23:10 <etoews> let's move on
16:23:11 <annegentle> miguelgrinberg: it's always good to address reviewers input so they keep reviewing :)
16:23:31 <etoews> #link https://review.openstack.org/#/c/155620/
16:23:52 <etoews> i haven't had a chance to look at that one yet
16:24:04 <etoews> looking good though
16:24:12 <elmiko> again, seems like we have good consensus among ourselves. no dissent yet...
16:24:25 <etoews> time to broaden it to the CPLs?
16:24:44 <elmiko> i think so
16:25:18 <etoews> miguelgrinberg: care to add the CPLs to the reviewers?
16:25:26 <miguelgrinberg> maybe add the same note about tags being UTF?
16:25:52 <etoews> sure
16:26:16 <miguelgrinberg> I'll push a new version for both in a little bit
16:26:25 * cdent makes UTF-8 4EVAH t-shirt
16:26:32 <sigmavirus24> cdent: so you want I-JSON, eh?
16:26:34 <sigmavirus24> =P
16:26:39 <cdent> heh
16:26:51 <cdent> I just can't stand that anyone uses anything else, ever
16:26:59 <etoews> #action miguelgrinberg to add note about UTF to https://review.openstack.org/#/c/155620/ and add CPLs to reviewers
16:28:04 <etoews> allow json in the api wg repo #link https://review.openstack.org/#/c/167869/
16:28:12 <etoews> what say you?
16:28:32 <cdent> +several
16:28:37 <elmiko> got my thumbs up ;)
16:28:47 <etoews> muchas gracias
16:30:39 <etoews> errors #link https://review.openstack.org/#/c/167793/
16:30:57 <etoews> i'm adding some of my own comments to that review right now.
16:31:20 <elmiko> i think it's a great idea, and i like the starting material
16:31:28 <cdent> I think needs to happen but it is unlikely to be a smooth transition
16:31:33 <elmiko> i wonder if we should engage with the log-wg too though?
16:31:38 <cdent> also, I'm curious about the use of 500 in some of the examples
16:31:48 <elmiko> this seems to border on their expertise as well
16:31:58 * sigmavirus24 hasn't read it
16:32:05 <miguelgrinberg> I like it
16:32:13 <cdent> what is the general feeling about 500 among this group? My feeling is it should almost never happen.
16:32:29 <cdent> (that is it should only happen on an uncaught exception)
16:32:41 <elmiko> i think 500 is appropriate if the server has some internal issue
16:32:45 <sigmavirus24> cdent: I would rather 500 become the default OK response
16:32:48 * sigmavirus24 jokes
16:32:59 <elmiko> sigmavirus24: ok, was gonna say...
16:33:20 <elmiko> the term "habitual line stepper" comes to mind ;)
16:33:26 <cdent> :)
16:33:32 <sigmavirus24> ¯\_(ツ)_/¯
16:33:36 <elmiko> hehe!
16:34:35 <jaypipes> etoews: sorry.
16:35:20 <annegentle> jaypipes: :) welcome
16:35:29 <etoews> cdent: so it's always a minefield when providing an example
16:36:10 <annegentle> etoews: that's a good example, the scheduler not finding a valid host happens a lot
16:36:13 <cdent> yeah etoews, it just seemed like it was being kind of encouraging of such things, and...well
16:36:15 <etoews> i made a note that it's a totally contrived example but i totally get that it's hard to see past the details.
16:36:31 <etoews> cdent: exactly. please comment on the review.
16:36:40 <annegentle> etoews: but is it really 500 they get back on scheduler failure (I'm looking)
16:36:44 <etoews> i should know better
16:36:57 <cdent> will do etoews
16:37:00 <jaypipes> miguelgrinberg: +2 from me on that. your answers make sense.
16:37:11 <etoews> example code has a way of becoming real code when people copy/pasta it literally
16:37:11 <elmiko> etoews: really stepped into this time
16:37:26 <etoews> thanks jaypipes :) no worries.
16:37:42 <miguelgrinberg> jaypipes: awesome, thanks
16:37:51 <elmiko> it's unfortunate that the example json files are the first in the review
16:37:53 <etoews> elmiko: :) i'm completely expecting this one to be a lightning rod
16:38:01 <etoews> i'm grabbing with both hands.
16:38:08 <elmiko> ha!
16:38:39 <etoews> i'd appreciate some feedback on my comments in that review too.
16:38:57 <etoews> and i still have 2 things left todo. (1) Get samples of errors from some of the services and (2) give the projects some guidance on how they could adopt this format.
16:39:25 <etoews> samples are easy. i can at the very least do a bad GET on a resource from the api
16:39:50 <elmiko> i'll ask again, should we get some input from the log-wg regarding possible error formats?
16:39:56 <etoews> (2) will be trickier but i'm hoping after (1) i can find a way
16:40:02 <elmiko> or at least pull them in on the review
16:40:06 <etoews> elmiko: yes! sorry i missed that.
16:40:19 <elmiko> cool, no worries
16:40:35 <etoews> i mentioned it in a comment on the front page of the review "I'd like to discuss this within the API WG first before broadening the discussion to the CPLs and the Logging WG."
16:41:16 <etoews> i consider the id and code properties to be the "interface" to the stuff the logging wg is doing.
16:41:36 <etoews> i tried to call that out explicitly in the schema
16:41:43 <miguelgrinberg> etoews: I mentioned this in a comment. Do we need a common list of codes for the errors all projects need to handle?
16:41:58 <elmiko> etoews: ok, cool. i must have missed that part.
16:42:28 <etoews> miguelgrinberg: one sec.
16:43:58 <etoews> miguelgrinberg: do you mean common codes that would go into the code property?
16:44:23 <miguelgrinberg> etoews: yes
16:44:30 <miguelgrinberg> and their associated hrefs
16:44:34 <etoews> the logging wg is working on that
16:44:40 <miguelgrinberg> ah okay, great
16:44:51 <etoews> the associated hrefs is an open question
16:45:06 <etoews> that's why i am considering making it optional
16:45:20 <miguelgrinberg> etoews: maybe that's a good idea
16:45:51 <etoews> i suppose projects could always "default" to linking to the api doc but that probably isn't super helpful because that's where the developer probably just came from ;)
16:46:18 <miguelgrinberg> yeah, should be included only if there is a meaningful link for it
16:46:29 <cdent> Is there not an existing emerging standard we can steal for this. I know much of this was framed on jsonapi, yeah. Can we not just do exactly what they do?
16:46:37 <etoews> as for common code to generate the errors that could be doable in oslo i think
16:46:50 <miguelgrinberg> eventually I hope we have that
16:46:54 <etoews> cdent: that was my original thought
16:47:03 <cdent> that would also allow for the common code
16:47:24 <etoews> and a lot is common but i don't think all of it is appropriate to openstack
16:47:53 <etoews> if we did change href to links, we'd certainly be breaking further away from json-apoi
16:47:57 <etoews> apoi
16:48:29 <etoews> i think that's a good start on that review. thanks for the comments.
16:48:31 <etoews> #topic Service catalog consistency
16:48:37 <annegentle> holla
16:48:41 <etoews> i believe annegentle added that one
16:48:59 <annegentle> so Sean Dague's interested in service catalog consistency from a QA standpoint, aren't we all.
16:49:18 <annegentle> so he asked what next steps were based on etoews ML post from Dec?
16:49:24 <annegentle> and I'm implicated as well :)
16:49:31 <annegentle> So I'm bringing it here
16:49:40 <annegentle> #link http://lists.openstack.org/pipermail/openstack-dev/2014-December/053295.html
16:49:49 <annegentle> I guess the next step is draft a guideline?
16:50:02 <elmiko> +1
16:50:06 <annegentle> Current state is here
16:50:08 <annegentle> #link https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog
16:50:41 <annegentle> So, my ask here is, 1) what additional analysis is needed of current state? and 2) is anyone interested in drafting guidelines?
16:50:49 <etoews> is dtroyer around?
16:51:41 <etoews> he inadvertently defined the defacto service catalog by virtue of devstack
16:51:42 <annegentle> I think what happens now is DevStack becomes a "standard"
16:51:46 <annegentle> heh right.
16:52:05 <etoews> :)
16:52:35 <annegentle> I'll let people read a bit, but let me know if you're interested, and what else we need to investigate. I can't clear my plate until after April, but I'm interested in working on it.
16:52:38 <etoews> i guess i was hoping someone from QA would step up and propose a guideline
16:53:00 <annegentle> yeah, that's a possibility too, they're looking for "where" and I'm saying "API-WG"
16:53:04 <annegentle> so I can also ask there
16:53:05 <etoews> i don't think any of us have the bandwidth right now
16:53:10 <annegentle> right.
16:53:31 <annegentle> Okay, let me know if anyone's interested, and I'll also ask Qa.
16:53:36 <etoews> thx annegentle
16:53:45 <etoews> #topic Capability Discovery API
16:53:56 <etoews> #link http://lists.openstack.org/pipermail/openstack-dev/2015-March/059284.html
16:54:16 <etoews> really just posting that there for visibility
16:54:54 <etoews> i'm not entirely sure what to do about it at this point
16:55:27 <elmiko> seems like a cool idea though
16:55:33 <etoews> we need to get people who want guidelines to also propose guidelines.
16:55:44 <etoews> maybe i'll prod them to do so
16:55:56 <elmiko> a novel idea ;)
16:56:32 <etoews> #topic meeting time
16:56:36 <elmiko> i wonder if it would be helpful if we had some sort of guideline template, like we do for specs?
16:56:43 <etoews> elmiko: +1
16:56:55 <etoews> elmiko: care to take a crack at it ;)
16:57:11 <elmiko> etoews: ok, i'll try to come up with something
16:57:28 <etoews> #action elmiko to try to come up with a guideline template
16:57:30 <etoews> thanks!
16:57:31 <elmiko> most likely i'll need help, but that's what reviews are for =)
16:57:51 <etoews> is that alternate meeting time killing anyone else?
16:58:06 <etoews> now with dst it's become almost impossible for me to attend
16:58:08 <elmiko> i can make it, but it is kinda late during dst
16:58:28 <annegentle> I can't ever make it regardless of dst sorry :(
16:58:35 <elmiko> =(
16:58:39 <etoews> do we change it?
16:59:03 <elmiko> i think we need to hear from the asia/australia/nz contingent
16:59:09 <elmiko> maybe something for the ML?
16:59:18 <etoews> ya. that was my feeling too.
16:59:31 <etoews> #action etoews to discuss changing meeting time on ML.
17:00:02 <etoews> time
17:00:07 <etoews> #endmeeting