16:01:51 <elmiko> #startmeeting api wg
16:01:52 <openstack> Meeting started Thu Aug 13 16:01:51 2015 UTC and is due to finish in 60 minutes.  The chair is elmiko. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:56 <openstack> The meeting name has been set to 'api_wg'
16:02:00 <cdent> o/
16:02:01 <jaypipes> afternoon all.
16:02:07 <elmiko> hi
16:02:22 <etoews> o/
16:02:24 <miguelgrinberg> hello
16:02:30 <edleafe> o/
16:02:32 <elmiko> #char jaypipes etoews
16:02:38 <elmiko> #chair jaypipes etoews
16:02:38 <openstack> Current chairs: elmiko etoews jaypipes
16:02:41 <elmiko> there we go
16:02:48 <stevelle> o/
16:02:52 <elmiko> #topic agenda
16:02:55 <cdent> so many chairs but nowhere to sit
16:03:03 <elmiko> #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
16:03:19 <sigmavirus24> o/
16:03:33 <sigmavirus24> elmiko: char them?
16:03:39 <sigmavirus24> why would we limit them to 255 bytes?
16:03:43 <elmiko> sigmavirus24: haha
16:03:49 <elmiko> i know, that would be so rude ;)
16:03:53 <sigmavirus24> or are we putting them on the barbi?
16:04:26 <elmiko> there were no action items last week, so we'll move on to new topics
16:04:30 <elmiko> #topic tokyo summit working group sessions
16:04:44 <elmiko> etoews, i think this was yours?
16:04:46 <etoews> that's me
16:05:02 <etoews> so i got an email from the summit organizers about some space/time for WGs.
16:05:18 <etoews> however, i almost certainly won't be at the tokyo summit.
16:05:41 <etoews> i just need someone i can forward that email to get some time/space for the wg
16:05:46 <elmiko> i hadn't responded to the email yet, but i *think* i will be there
16:06:30 <etoews> jaypipes: will you be there?
16:06:31 * cdent looks at jaypipes
16:06:33 <cdent> jinkx
16:06:36 <jaypipes> etoews: yes.
16:06:58 <jaypipes> etoews: feel free to forward.
16:07:36 <etoews> i already forwarded it on the 11th. subject: Working Group Space Sign-Up for Tokyo - OpenStack Summit
16:08:00 <elmiko> anything else on this topic?
16:08:02 <etoews> i'd suggest cc'ing elmiko to keep him in the loop
16:08:05 <etoews> thx!
16:08:07 * jaypipes checks spam folder...
16:08:19 <cdent> I assumed this topic was "what should the session be"
16:08:25 <elmiko> yea, i'm fairly sure i'll be in tokyo, just haven't booked yet
16:08:30 <cdent> not "how should we make sure they happen" (which is important too)
16:08:42 <elmiko> we can talk about that too =)
16:08:54 <etoews> cdent: it's entirely up to us what to do with it
16:09:04 <etoews> last summit i grabbed 3 timeslots
16:09:10 <elmiko> i was imagining we would at least have a "state of wg" type session
16:09:14 <etoews> the first for a "state of the wg"
16:09:19 <elmiko> jinx!
16:09:24 <cdent> did they already give us a known set of slots, or asking for how many we want?
16:09:26 <etoews> and the other 2 for actual working sessions
16:09:47 <etoews> they're asking
16:09:47 <jaypipes> etoews: was in spam folder. will respond.
16:10:01 <elmiko> jaypipes: a likely story... ;)
16:10:33 <elmiko> i'm guessing we'll put up an etherpad for ideas on the working sessions?
16:10:34 <cdent> 3 seems good
16:11:51 <jaypipes> cdent: I'm not entirely sure we need 3. making it to 2 would be a stretch for me, frankly. not just API WG sessions, but any session not nova is hard for me to attend.
16:12:22 <jaypipes> but if there are proposals for specific topics we think will take >2 sessions, OK.
16:12:39 <cdent> I was thinking 1. state of the wg 2. talking about the future 3. shooting the breeze for giggles
16:12:44 <elmiko> i tend to agree with jaypipes, except replace nova with sahara
16:12:46 <cdent> 3 being very optional
16:13:02 <elmiko> ok, i can get down with that idea
16:13:10 <jaypipes> cdent: heh, sure.
16:13:32 <cdent> from what I can recall: you take slots that you _might_ need and then start giving them back when they start struggling to schedule everything
16:13:55 <elmiko> lol, fair
16:14:16 <jaypipes> cdent: would you like to organize the tokyo API WG stuff?
16:14:30 <jaypipes> cdent: I personally have trouble finding the bandwidth.
16:14:35 <jaypipes> not sure about elmiko
16:15:02 <elmiko> i don't mind helping, but if cdent wants to take lead i'm cool with that
16:15:05 <cdent> jaypipes: I can take it if elmiko doesn't want it, but I've had a lot of bandwidth suffering this cycle (probably not near as much as you though)
16:15:32 <elmiko> cdent: you wanna take lead with me as backup?
16:15:55 <cdent> you have much more state on the state of the group. How about you worry about content, and I'll worry about orchestration?
16:16:03 <elmiko> hehe ok
16:16:19 <elmiko> #action cdent to orchestrate tokyo sessions
16:16:23 <cdent> somebody bounce me the email please and I'll see what can happen
16:16:30 <elmiko> #action elmiko to work on content for tokyo sessions
16:16:30 <salv-orlando> elmiko, jaypipes: you can count on my help, if I can assist in nay way
16:16:40 <elmiko> salv-orlando: awesome, thank you!
16:16:44 <jaypipes> salv-orlando: cheers, much appreciated.
16:17:03 <elmiko> #info 3 sessions proposed for tokyo, state of the wg, future plans, happy hour
16:17:29 <cdent> s/happy hour/how we gonna solve this bandwidth problem everyone seems to have all the time
16:17:41 <elmiko> +1
16:17:54 <elmiko> ok, lets work on the sessions on an etherpad to be setup
16:18:16 <cdent> +1
16:18:40 <elmiko> #link https://etherpad.openstack.org/p/mitaka-api-wg-session-plans
16:18:55 <elmiko> moving on
16:19:01 <elmiko> #topic guidelines
16:19:28 <elmiko> hmm, looks like i messed up the agenda a little
16:19:42 <elmiko> we currently have 3 frozen
16:20:10 <elmiko> and thanks to ryansb for updating the headers guideline
16:20:36 <elmiko> there is also a question about creating a PATCH guideline to address the rfc6902 vs. partial update methodology questions
16:21:06 <elmiko> looking for volunteers on that one, but if not i think i can address it
16:21:34 <elmiko> also, i think we need to get a few more reviews in on the open guideliness to prepare more for the next freeze cycle
16:22:24 <elmiko> the dashboard that etoews put together is working quite nicely (aside from freeze stuff being in question), i'd recommend folks to take a look at the gerrit-dashboard-generator if they haven't seen it
16:22:40 <etoews> #link http://ghostcloud.net/openstack_gerrit_dashboards/dashboard_api-wg.html
16:22:41 <elmiko> #link http://ghostcloud.net/openstack_gerrit_dashboards/dashboard_api-wg.html
16:22:45 <elmiko> hehe
16:22:53 <etoews> we're just full of jinxes this meeting
16:22:53 <jaypipes> elmiko: just finishing up reviews on the remaining ones I haven't reviewed.
16:23:00 <elmiko> are there any guidelines folks would like to bring up?
16:23:04 <elmiko> etoews: yea, totally!
16:23:13 <elmiko> jaypipes: ack, thanks
16:24:29 <elmiko> ok, well the main one i'm curious about is sdague's guideline about 501s
16:24:38 <elmiko> which i'm having trouble finding right at the moment
16:24:59 <elmiko> #link https://review.openstack.org/#/c/183456/
16:25:23 <elmiko> this had gone up for freeze and was sent back, but we are having trouble coming to a consensus on it
16:25:24 <cdent> I think we need to bite the bullet and declare that the wg has authority and stop working towards consensus
16:25:34 <elmiko> yea, that's kinda the question
16:25:43 <elmiko> when to we call off debate and merge something?
16:25:49 <elmiko> *do
16:26:03 <jaypipes> elmiko: good question.
16:26:37 <edleafe> cdent: authority to issue guidelines, sure
16:26:47 <elmiko> i'm not really sure the best answer on this one, etoews did you have any thoughts about this circumstance?
16:27:04 <etoews> #link http://specs.openstack.org/openstack/api-wg/process.html
16:27:26 <etoews> In the guideline review, consensus means the changeset must be available for review in its near final form for at least 2 working days. Minor typo/formatting change updates do not reset the counter. There must be at least four +1 votes and no -1’s unless the concern by the -1 vote has been discussed in an API WG meeting. Once the matter has been discussed
16:27:26 <etoews> there should be no more than 20% (of votes cast) -1 votes.
16:27:59 <elmiko> ok, i guess we should move ahead with merging then
16:28:33 <salv-orlando> also at the end of the day is a guideline, not a law.
16:28:38 <elmiko> true
16:28:39 <etoews> if it's been discussed then yes
16:28:55 <elmiko> yea, this one has been jammed in the pipeline for quite awhile
16:29:29 <etoews> -1s are showstoppers. we're going for consensus, not unanimity
16:29:40 <etoews> -1s are *not* showstoppers
16:29:49 <elmiko> so, aside from miguelgrinberg's comments about grammar, i guess we can fix and merge
16:30:04 <elmiko> or should we merge and apply a fix patch?
16:30:54 <salv-orlando> both work for me... for what concern me you can fix the grammar with a new patchset and then merge
16:31:11 <salv-orlando> without bothering the committer
16:31:24 <elmiko> ok, cool
16:31:37 <elmiko> moving on
16:31:46 <elmiko> #topic guideline pipeline
16:31:51 <cdent> I wanted to mention my pending guideline: https://review.openstack.org/181912
16:32:10 <cdent> just as a sort of question about some of the difficulties we are encountering
16:32:45 <elmiko> yea, i guess, given what we just said this could merge on the 18th
16:32:54 <elmiko> assuming there isn't an influx of -1s
16:33:00 <cdent> that one was written with a very specific purpose but much of the comments have been about clarifying basics of POST and PUT, which I had assumed in initial writing would be or are covered elsewhere
16:33:19 <cdent> reviewing these kinds of guidelines, out of context, will always result in those kinds of queries
16:33:36 <cdent> "you forgot to mention X", "no, I left that out on purpose"
16:33:37 <cdent> etc
16:33:47 <elmiko> imo, i think it's ok for us to have these specific style guidelines with that assumption
16:33:52 <salv-orlando> sure. Indeed for instance I believe the comment on response code is out of scope
16:34:02 <elmiko> we just need to make sure that we go back and fill in the prior art, as it were
16:34:23 <cdent> makes sense
16:35:19 <etoews> and the response codes are covered in http://specs.openstack.org/openstack/api-wg/guidelines/http.html#xx-success-codes
16:35:39 <elmiko> good point
16:36:20 <salv-orlando> on the other hand, as I'm myself a pedant reviewer, I also understand the reviewers' point of view
16:36:27 <cdent> Yeah, I was just wondering if there is something we can add to the process so that people are aware of the focus of the pieces when doing reviews
16:36:39 <cdent> salv-orlando: :)
16:36:47 <etoews> bknudson does have a point about responding with the URI. it's a bit ambiguous as is.
16:36:48 <cdent> or rather: does it matter
16:36:53 <elmiko> hmm, interesting idea cdent. maybe we just need to be more vocal on the review comments
16:36:54 <salv-orlando> I believe that from the perspective of forming a "consensus" the core team might retain the faculty of excluding -1s for out of scope comments
16:37:16 <etoews> cdent: the focus of the pieces should be apparent from the commit message
16:37:19 <elmiko> salv-orlando: yea, i tend to agree with that line of reasoning
16:37:44 <cdent> elmiko: Yeah, I think being more vocal in review comments is great and fine.
16:38:13 <cdent> I'm not whining here: Oh noes I got comments and now I have to deal with them. Rather: are we cool with the ways things go? If so, cool.
16:38:40 <elmiko> i think so, we just need to be firm i suppose about the focus of the individual guidelines
16:39:02 <elmiko> and make sure that when merging a guideline with -1s that we address the situation in the merge comment
16:39:14 <etoews> elmiko: good point
16:39:58 <elmiko> ok, so the guideline piplie and dashboard were etoews' topics from before, did have any comments on the dashboar etoews?
16:40:04 <elmiko> *pipeline
16:40:51 <etoews> elmiko: let's talk about improvements to merging guidelines first. that will inform any changes to the dashboard.
16:40:57 <elmiko> ack
16:41:07 <elmiko> #topic merge guidelines
16:41:20 <elmiko> so, yea, -2 can be problematic in some cases
16:41:32 <etoews> yep
16:41:47 <elmiko> -A could work, but then removes the ability to make WIP stuff
16:42:03 <elmiko> the -infra folks recommended that this may be more a social contract issue for the wg than a technical issue
16:42:06 <elmiko> but,
16:42:13 <elmiko> that makes the dashboard a little less tidy ;)
16:42:29 <elmiko> so... ideas?
16:44:06 <elmiko> i had thought about maybe using a special topic branch name to help guide this, but then it doesn't look like cores can just change the topic name at will. (without a new revision)
16:44:17 <etoews> i think, in general, we won't have so many WIP guidelines.
16:44:26 <jaypipes> elmiko: I think just having you or etoews add a comment like you do saying "Frozen on <date>" is fine.
16:44:42 <salv-orlando> elmiko: if you only change topic for the patch, the votes are preserved, I think
16:44:53 <jaypipes> elmiko: and that serves as a reminder for items on the weekly meetings, too.
16:45:03 <etoews> jaypipes: the trick is using something that we can surface in the dashboard.
16:45:16 <elmiko> right, what etoews said
16:45:28 <elmiko> that's why i was thinking topic branch, we can filter on it
16:45:35 <jaypipes> etoews: I see... yes, that's a good point.
16:45:40 <cdent> what about 1 +2 means frozen?
16:45:52 <elmiko> that's a decent idea
16:45:55 <cdent> and the social part is that the +2 capable people ahve to collaborate
16:46:06 <elmiko> right, we just use +1 until we are ready to freeze
16:46:06 <jaypipes> cdent: gotcha. yeah, I that might work.
16:46:20 <etoews> and the other cores just +1 to vote
16:46:26 <elmiko> i kinda like that idea
16:46:33 <cdent> it's simple but quite visible
16:46:46 <jaypipes> +1 to that ;)
16:46:58 <etoews> ++
16:47:00 <elmiko> +1
16:47:08 <jaypipes> nice idea, cdent
16:47:15 <edleafe> yes, good idea
16:47:17 <etoews> i'll take the action item here
16:47:25 <elmiko> cool, thanks
16:47:47 <elmiko> #action etoews to update process doc with +2 freeze comments
16:47:50 <etoews> #action update process for 1 +2 freeze and update dashboard to reflect this
16:48:06 <cdent> go me!
16:48:10 <elmiko> oops
16:48:26 <etoews> can never have enough jinxed action items
16:48:44 <elmiko> ok, so that clears up that issue and the dashboard stuff, with about 10min, left for APIImpact
16:48:59 <elmiko> n
16:49:06 <elmiko> #topic APIImpact
16:49:18 <elmiko> #link https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
16:49:43 <elmiko> anyone have a review they'd like to bring up?
16:50:52 <elmiko> i'm working on the v2 API spec for sahara, i would love any comments/criticism/suggestions on #link https://review.openstack.org/#/c/212172/
16:51:46 <etoews> this looks interesting as well #link https://review.openstack.org/#/c/182016/6/specs/liberty/api-v2-structured-data-format.rst,unified
16:53:11 <elmiko> yea, interesting
16:53:32 <etoews> elmiko: in yours, is job a hadoop job?
16:53:53 <elmiko> etoews: yea, hadoop, spark, storm, really any of the frameworks we support
16:54:00 <etoews> ah yes
16:55:19 <etoews> looks like designate is using vendor media types
16:55:42 <cdent> etoews: are you pro or con?
16:56:38 <etoews> i lean towards pro but don't have enough direct experience with them to have a definitive opinion
16:57:27 <elmiko> i wonder, are they using the types to help inform the server app how to handle the requests?
16:58:48 <cdent> in my experience they are the better way to do versioning than /v2 or the way microversions are being implemented
16:59:04 <cdent> persistent uris with fungible representations
16:59:22 <elmiko> i like that idea too, but it seems to be "controversial" in some places
16:59:30 <elmiko> also, <1min left
16:59:50 <etoews> i like what i'm seeing here https://review.openstack.org/#/c/203948/
16:59:56 <etoews> (from the commit message anyway)
17:00:16 <elmiko> yea, +1
17:00:24 <elmiko> ok, we're out of time, thanks everyone!
17:00:29 <elmiko> #endmeeting