00:00:06 <etoews> #startmeeting api wg
00:00:10 <openstack> Meeting started Thu Jul  9 00:00:06 2015 UTC and is due to finish in 60 minutes.  The chair is etoews. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:00:14 <openstack> The meeting name has been set to 'api_wg'
00:00:23 <elmiko> hey
00:00:47 <etoews> well hello
00:01:42 <alex_xu> o/
00:01:51 <etoews> yay!
00:02:07 <etoews> one sec. i have to pull some brussel sprouts off the bbq.
00:02:14 <elmiko> nice
00:03:54 <etoews> alright. that takes care of the first agenda item.
00:04:00 <elmiko> lol
00:04:04 <etoews> #topic agenda
00:04:11 <etoews> #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
00:04:21 <etoews> #topic previous meeting action items
00:04:31 <etoews> #link http://eavesdrop.openstack.org/meetings/api_wg/2015/api_wg.2015-07-02-16.00.html
00:04:50 <etoews> ha. no action items. i remember now.
00:04:58 <etoews> #topic dashboard
00:05:05 <etoews> #link https://review.openstack.org/#/c/198826/
00:05:22 <elmiko> i like what you've done so far
00:05:27 <etoews> okay. this one is pretty important.
00:05:27 <etoews> thx
00:05:56 <etoews> it's impossible to keep track of where guidelines are in the merging pipeline
00:06:08 <elmiko> yea
00:06:11 <etoews> we need this dashboard to show that at a glance.
00:06:27 <alex_xu> how to use that?
00:06:36 <etoews> alex_xu: 1 sec.
00:06:36 <elmiko> i think we might also need an indicator of when a guideline is ready for freeze
00:07:35 <etoews> git clone https://github.com/stackforge/gerrit-dash-creator.git
00:07:36 <etoews> cd gerrit-dash-creator/
00:07:36 <etoews> git review -d 198826
00:07:36 <etoews> ./gerrit-dash-creator dashboards/api-wg.dash
00:08:01 <etoews> alex_xu: that's what you need to do to see it in its current state
00:08:15 <alex_xu> etoews: thanks
00:08:31 <etoews> i'm on a mac so i change the last line to
00:08:31 <etoews> ./gerrit-dash-creator dashboards/api-wg.dash | pbcopy
00:08:41 <etoews> and paste the url into my browser
00:09:03 <alex_xu> I see now, that is used to generate url
00:09:10 <etoews> elmiko: there's a section titled "Ready to freeze"
00:09:18 <elmiko> ah, cool
00:10:36 <etoews> except it doesn't work right all of the time
00:10:55 <elmiko> well, and my issue was more about if things have been sitting for awhile and not getting reviews
00:11:02 <elmiko> case in point the 5xx stuff
00:11:33 <elmiko> i was hoping for more reviews before we froze, and there are some issues coming up. but maybe that's a good thing
00:11:47 <elmiko> i certainly needed some advice on how to improve it
00:12:47 <etoews> elmiko: i know what you mean. can you think of a way to codify that in the dashboard?
00:12:57 <elmiko> sadly no
00:13:41 <elmiko> that's the real meat of the issue, getting more involvement on guidelines that have some warts but need reviews
00:13:57 <etoews> i expect no matter what we do we'll still need to verify what's going on in the dashboard vs what actually needs to happen.
00:14:04 <elmiko> agreed
00:14:07 <etoews> it'll be a judgement call
00:14:53 <etoews> for example, "Add generic name of each project for terms" should be in "Ready to freeze" but isn't :(
00:15:12 <elmiko> huh, weird
00:15:33 <elmiko> is the age parameter a "greater than" ?
00:15:42 <elmiko> (hasn't created dashboards before)
00:16:28 <etoews> neither have i. that's why i could use more eyes on it.
00:16:34 <etoews> have a look at "Merged in the past 7 days"
00:17:01 <etoews> i use -age there to get the past 7 days
00:17:05 <elmiko> yea
00:17:55 <elmiko> i'll play around with your patch a little more and give some comments on the review
00:18:55 <etoews> #link https://review.openstack.org/Documentation/user-search.html
00:19:10 <elmiko> ah, very good ty
00:19:12 <etoews> age:'AGE'
00:19:13 <etoews> Amount of time that has expired since the change was last updated with a review comment or new patch set.
00:19:58 <etoews> i really just took one of the existing dashboards and started hacking at it. it needs more work.
00:21:03 <elmiko> well, it's a nice start =)
00:21:44 <etoews> so "Add generic name of each project for terms" got a +1 on Jul 7 12:23 PM
00:22:18 <etoews> from the definition on age there this is starting to make sense
00:22:23 <elmiko> i'm assuming that counts as a comment
00:22:29 <etoews> ya
00:22:56 <elmiko> i wonder if the gerrit machines are using utc time for these calcs?
00:23:03 <etoews> so a review has to be quiet for 2 days before it can be considered for freeze
00:23:29 <elmiko> can we say quiet for 2 days *and* has X many +1/2s ?
00:25:14 <etoews> hmmm...looking at https://review.openstack.org/Documentation/user-search.html#labels
00:25:52 <etoews> i think the answer is no
00:26:13 <elmiko> ah well
00:27:12 <etoews> i guess i'm okay with the "has to be quiet for 2 days" thing too.
00:27:24 <etoews> it's not exactly what's in http://specs.openstack.org/openstack/api-wg/process.html but it's not so far off either.
00:27:39 <elmiko> fair
00:30:46 <etoews> i don't think "Frozen but needs feedback" is working right either.
00:31:04 <etoews> "Should not return server-side tracebacks" should be in there
00:32:16 <elmiko> hmm, i see that and 5xx in there
00:33:00 <etoews> well 5xx does have that one -1
00:33:16 <etoews> which is what i intended to capture with
00:33:17 <etoews> query = status:open (label:Code-Review=-2 AND label:Code-Review=-1)
00:33:32 <elmiko> right, but so does the other one
00:33:41 <etoews> ya...
00:34:41 <etoews> oh wait "Should not return server-side tracebacks" appears in both
00:35:19 <elmiko> yea
00:36:22 <etoews> ah i understand now.
00:36:25 <etoews> got the fix too.
00:36:37 <etoews> [section "Frozen"]
00:36:38 <etoews> query = status:open (label:Code-Review=-2 AND NOT label:Code-Review=-1)
00:36:56 <elmiko> lol, was just wondering.. "AND NOT"
00:37:18 <etoews> okay. i'll update it.
00:37:35 <etoews> elmiko: can you give the dashboard a thorough look?
00:37:45 <elmiko> yep
00:37:48 <etoews> thx
00:38:05 <etoews> #action elmiko to give the dashboard a thorough review
00:38:29 <etoews> thanks for chatting through that with me.
00:38:39 <elmiko> np =)
00:38:41 <etoews> #topic [Solum] Request for feedback on new API resource
00:39:01 <etoews> #link http://lists.openstack.org/pipermail/openstack-dev/2015-June/067811.html
00:39:24 <etoews> i keep back burnering this request for our advice/help :(
00:39:30 <elmiko> doh!
00:41:04 <etoews> so they've got some of their api in they spec linked to there
00:41:10 <etoews> #link https://github.com/stackforge/solum-specs/blob/master/specs/liberty/app-resource.rst
00:41:48 <etoews> care to take a minute to look?
00:42:01 <elmiko> yea, looking now. this is kinda in-depth
00:43:52 <elmiko> not sure i dig the .../workflows endpoint, but then i'm more on jaypipe's side of things with tasks as resources
00:44:36 <elmiko> on a first pass it seems reasonable though (workflows aside)
00:44:42 <etoews> not there yet...
00:45:36 <elmiko> and i'm not sure about the PATCH call, but then i'm not super familiar with the semantics around PATCH
00:45:45 <etoews> i noticed that too
00:45:56 <etoews> have a look at this https://review.openstack.org/#/c/183945/5/guidelines/http.rst
00:46:20 <elmiko> lol, i knew that sounded familiar
00:46:45 <etoews> you know, the workflows thing might be okay.
00:46:55 <etoews> it looked like rpc to me at first too
00:47:09 <etoews> but check out "wf_id": 34
00:47:24 <etoews> it seems to be creating a distinct resource
00:47:53 <etoews> yep
00:47:54 <etoews> GET /apps/94cb7b89-0de8-492b-bf54-05ae96c9bd0e/workflows/37
00:48:16 <elmiko> ok, that makes a little more sense
00:48:26 <elmiko> missed that part
00:49:31 <etoews> okay. i'll reply on the ml with a couple of things.
00:49:36 <elmiko> cool
00:49:46 <elmiko> in general, seems sensible
00:49:50 <etoews> i think so
00:49:52 <etoews> #topic vacation
00:50:02 <etoews> i'm going on vacation :)
00:50:09 <elmiko> yay \o/
00:50:18 <elmiko> hope its somewhere fun =)
00:50:48 <etoews> first headed back to canada to see friends and family and then to cancun for my brother's wedding.
00:50:58 <elmiko> ooh, nice
00:51:11 <etoews> i'm effectively out until august 6th
00:51:30 <etoews> (i'll be back for less than a week in the middle of that)
00:51:37 <elmiko> k, we'll keep the ship tidy in your absence ;)
00:51:47 <etoews> how did you know that was my next question?
00:51:51 <elmiko> haha
00:52:08 <etoews> you are a gentleman and a scholar.
00:52:17 * elmiko tips fedora
00:52:19 <elmiko> too kind sir
00:52:22 <etoews> :D
00:52:32 <etoews> #action elmiko to keep the ship tidy :)
00:52:36 <elmiko> LOL
00:52:51 <etoews> #topic guidelines
00:53:11 <etoews> Adding 5xx guidance, could use some clarification about issues raised on review #link https://review.openstack.org/#/c/183698/
00:53:25 <elmiko> i think we might need to punt on this till more folks are around, not sure
00:53:33 <elmiko> i'd like some thoughts on the 501 comments
00:54:00 <elmiko> also, the idea of us duplicating information about 5xx codes
00:55:39 <etoews> "application code" is a bit ambiguous but yes.
00:55:49 <etoews> i still think this is an important guideline
00:55:53 <elmiko> yea, i'm gonna change that per Jonh's suggestions
00:55:58 <elmiko> John
00:56:08 <etoews> johan
00:56:15 <elmiko> hehe
00:56:26 <etoews> anything to chat about?
00:56:30 <etoews> alex_xu?
00:56:34 <bknudson> would be interesting to get api wg feedback on https://review.openstack.org/#/c/192422/3/specs/backlog/policy-by-url.rst (see line 35)
00:56:49 <elmiko> i'd really like some feedback on that barbican apiimpact linked
00:57:13 <bknudson> looks like an abomination to me, but the submitter likes it
00:57:40 <elmiko> yea, that URI is a mouthful
00:58:01 <etoews> everyone's child is beautiful in their own eyes :)
00:58:35 <elmiko> fwiw i think this is a useful feature
00:58:40 <bknudson> the question is the use of query parameters on a PUT
00:58:55 <bknudson> maybe there's already API guidelines
00:58:55 <etoews> at this point it's probably best to throw those out on #openstack-api tomorrow and see if we can get more eyes on them
00:58:59 <elmiko> yea, not sure about that
00:59:29 <elmiko> i suggested something similar on a POST call for that barbican spec
00:59:55 <elmiko> i don't see the issue with adding a query parameter though, but i might just be missing something
01:00:18 <etoews> time
01:00:24 <etoews> #endmeeting