16:00:31 <elmiko> #startmeeting api sig
16:00:31 <openstack> Meeting started Thu Mar 15 16:00:31 2018 UTC and is due to finish in 60 minutes.  The chair is elmiko. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:35 <openstack> The meeting name has been set to 'api_sig'
16:00:40 <edleafe> \o
16:00:41 <elmiko> #chair cdent elmiko edleafe dtantsur
16:00:42 <openstack> Warning: Nick not in channel: cdent
16:00:43 <dtantsur> o/
16:00:44 <openstack> Current chairs: cdent dtantsur edleafe elmiko
16:01:15 <elmiko> #link https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
16:01:30 <cdent> sigh. tc again
16:01:32 <elmiko> welcome, sir
16:01:34 <elmiko> np
16:01:38 <elmiko> #topic previous meeting action items
16:02:01 <elmiko> i missed last meeting, looks like no action items?
16:02:11 <dtantsur> well, continue with the PTG items
16:02:16 <elmiko> ack
16:02:24 <elmiko> any status on those?
16:02:37 <edleafe> I haven't done mine yet
16:02:52 <edleafe> just finally published my PTG blog yesterday :)
16:02:53 <cdent> i have a question about one of mine, but it is listed elsewhere in the agenda
16:03:11 <dtantsur> I have updated the versions-in-SDKs guideline
16:03:11 <elmiko> fair
16:03:16 <dtantsur> accordingly to what we discussed back then
16:03:21 <dtantsur> * according
16:03:22 <elmiko> ++
16:03:45 <edleafe> dtantsur: have it open in a tab, only got through the first two paragraphs so far
16:04:15 <dtantsur> ah, the ones that were not changed :D
16:04:26 <edleafe> heh
16:04:34 <elmiko> i need to review mugsie's stuff still, i will get that in the next week
16:05:06 <elmiko> #topic open mic and ongoing or new biz
16:05:29 <elmiko> anyone wanna comment on what is missing from the http methods doc?
16:05:40 <elmiko> #link http://specs.openstack.org/openstack/api-wg/guidelines/http.html#http-methods
16:06:10 <edleafe> cdent: was that yours?
16:06:32 <cdent> yeah
16:06:52 <cdent> so I had an action to write up a field guide to the http methods
16:07:00 <cdent> and went to check what we already had, which is pretty complete
16:07:11 <cdent> so thought I would check to see what's missing before I try to fix anything
16:07:23 <elmiko> that sounds worthwhile to me
16:07:38 <edleafe> are you thinking like a high-level summary?
16:07:48 <cdent> well I dont know, because it is already a pretty high level summary
16:07:56 <edleafe> something like "You want to update a foo. You should do it this way: ..."
16:07:58 <cdent> so I'm wondering if maybe nothing needs to be done
16:08:50 <elmiko> kinda sounds like that
16:09:16 <elmiko> maybe increase the visiblity for that section?
16:09:18 <edleafe> Nothing is jumping out at me
16:09:53 <cdent> I still have a different action which is a sort unabridged table of contents to the guidelines, which would probably help the visibility problem
16:10:11 <elmiko> ++
16:10:15 <cdent> If we think the content that's currently there for methods is okay, I'll focus on the different actin instead
16:10:34 <elmiko> should we take an action to review that section for content?
16:10:43 <cdent> seems like a good idea
16:10:45 <dtantsur> at least some grouping of the list of guidelines
16:11:12 <elmiko> #action everybody read the http-methods guideline with an eye for missing content
16:11:36 <elmiko> or should we make it hte whole http doc?
16:12:02 <cdent> may as well be the whole doc?
16:12:14 <elmiko> i'm good with that
16:12:15 <elmiko> #undo
16:12:17 <openstack> Removing item from minutes: #action everybody read the http-methods guideline with an eye for missing content
16:12:24 <elmiko> #action everybody read the http guideline with an eye for missing content
16:12:59 <elmiko> any other topics for open mic?
16:13:27 <cdent> not from me
16:13:45 <elmiko> moving right along then
16:13:47 <elmiko> #topic guidelines
16:13:53 <elmiko> #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
16:13:59 <elmiko> #link https://review.openstack.org/#/q/status:open+project:openstack/api-sig,n,z
16:14:29 <elmiko> i guess we need some reviews on the microservice and cache-control prs
16:15:04 <elmiko> and maybe reach out Gilles about the schema thing? (i know that's tied up with the os-api-ref changes too)
16:16:09 <elmiko> any other thoughts or comments here?
16:16:15 <dtantsur> I might have missed some comments (e.g. IIRC cdent's) while updating my spec - please lemme know if they still apply
16:16:23 <cdent> Unless someone wants to pick it up, we could consider abandoning sean's microversion history doc
16:16:37 <edleafe> None, other than when things get busy, my focus on the API-SIG stuff suffers
16:16:58 <dtantsur> it's the case for all us, I guess
16:17:08 <elmiko> i can take an action to look at sean's doc
16:17:28 * mlavalle would like to ask question at the end of the meeting
16:17:42 <elmiko> #action elmiko review https://review.openstack.org/#/c/444892/ for relevance
16:17:48 <elmiko> mlavalle: sure thing
16:18:13 <dtantsur> I dunno how I feel about that doc...
16:18:18 <edleafe> mlavalle: we now charge $5 to ask a question
16:18:27 * elmiko chuckles
16:18:32 <mlavalle> LOL
16:18:35 <dtantsur> it seems a bit like an attempt to provide a justification for the already made decision
16:18:36 <elmiko> dtantsur: please add a comment to the review =)
16:18:37 <dtantsur> hehe
16:18:44 <dtantsur> yep, will do
16:18:46 <elmiko> thanks!
16:19:18 <elmiko> imo, sometimes it's nice to have the engineering history captured for newcomers to read up on, but i get what you are saying dtantsur
16:19:23 <edleafe> dtantsur: yeah, I remember a summit session or blog post or something like that from Sean that started this line of microversion explanation
16:19:49 <edleafe> It was more to explain *why* those decisions were made for those who came later
16:20:08 <elmiko> i think that is worthwhile info to capture
16:20:15 <edleafe> Imagine if the US Founding Fathers had bothered to do that :)
16:20:29 <dtantsur> lol
16:20:37 <elmiko> i /may/ not be the best person for keeping that history from the doc, but i can at least review it and see if we can get there
16:20:41 <dtantsur> well, I'd prefer it also covered downsides...
16:21:30 * cdent waves at mlavalle
16:21:35 <cdent> woot, missed doing that
16:21:36 <elmiko> given the preference for microversions, is there a situation where we could actually advise a project *not* to use them?
16:21:46 <edleafe> dtantsur: wait - microversions have downsides?
16:21:53 <edleafe> :)
16:21:55 <elmiko> edleafe: ++
16:21:57 <dtantsur> LOOOL
16:22:09 <dtantsur> elmiko: API barely ever changes?
16:22:15 <elmiko> i'm cool with pointing out the downsides if we agree that in some cases we could advise that path
16:22:37 <elmiko> dtantsur: yeah, seems like more work for little gain there
16:22:50 <dtantsur> well, the downsides (like complex implementation or being confusing as hell) exist even if we don't have better alternatives
16:22:56 <elmiko> well, let's discuss it on the review. i think it would be good to capture this conversation there
16:23:00 <dtantsur> yep
16:23:01 <elmiko> true
16:23:29 <elmiko> #topic bug review
16:23:35 <elmiko> #link https://bugs.launchpad.net/openstack-api-wg/+bugs?orderby=-id&start=0
16:23:43 <elmiko> #link https://bugs.launchpad.net/openstack-api-sig/+bugs?orderby=-id&start=0
16:23:46 <elmiko> anything new here?
16:24:06 <elmiko> i guess just the cache-control stuff
16:24:14 <elmiko> but we are addressing that with the guideline?
16:24:14 <cdent> dtantsur: speaking of complex microversion implementatins, you should totally lend your review to my active changes on microversion-parse
16:24:22 <elmiko> ++
16:24:27 <dtantsur> cdent: /me adds to gertty
16:25:05 <elmiko> anything else to say on bugs?
16:25:32 <elmiko> ok then
16:25:37 <elmiko> #topic open mic, round 2
16:25:43 <elmiko> mlavalle: the floor is yours
16:26:20 <mlavalle> cdent was very nice to respond to our question here: http://lists.openstack.org/pipermail/openstack-dev/2018-March/128023.html
16:26:58 <mlavalle> the implication is that Neutron has a buggy API as far as filters
16:27:11 <mlavalle> we are going to fix it
16:27:24 <elmiko> not buggy, non-conforming to the guidelines ;)
16:27:30 <mlavalle> yeap
16:27:50 <elmiko> and glad to hear it is helping provide a direction =)
16:27:59 <mlavalle> the question is. Should we keep the previous API behavior?
16:28:14 <mlavalle> in other words, make the fixed one configurable and dicoverable
16:28:28 <edleafe> It can be a bug if the user thinks they are requesting things, but there is a typo and the server returns something other than what was expected
16:28:31 <mlavalle> but let the user keep the previous one
16:28:35 <elmiko> wouldn't you need to keep the old for historical microversions?
16:28:49 <elmiko> edleafe: good point
16:29:06 <edleafe> elmiko: if it's considered a bug, you should *not* keep the old behavior
16:29:24 <edleafe> if it's considered a feature (flexibility!), then yes, you need to keep that option
16:29:26 <mlavalle> we don't have bugs reported against the current behavior
16:29:59 <mlavalle> we discovered the way it is behaving and want to make it consistent
16:30:00 <elmiko> edleafe: 100% agree
16:30:10 <mlavalle> with the guidelines
16:30:33 <elmiko> so, i guess this kinda turns it back around to edleafe's point
16:30:40 <mlavalle> so I am thinking that we should give users a way to keep the old behavior if they want to
16:30:47 <elmiko> is the old behavior considered buggy, even if none have been reported?
16:30:51 <edleafe> mlavalle: so is anyone *depending* on the current behavior that you know of?
16:30:57 <elmiko> ++
16:31:25 <mlavalle> edleafe: we don't really know, but we don't want to potentially break tooling that accounts for the current behavior
16:31:48 <elmiko> that sounds like a strong case for keeping it
16:32:16 <mlavalle> yes, that's what I thought
16:32:17 <edleafe> you'd have to get the input from the tooling maintainers on that, then
16:32:24 <cdent> I'm trying to imagine the tooling that adapts and I suppose things that do dynamic query generation might be impacted
16:33:38 <cdent> mlavalle: what's the cost of keeping it?
16:33:52 <edleafe> So here's what I see: there is a valid parameter named 'foo', but a tool is now calling the API with 'f00'. You make the change, and all of a sudden they are getting 400s back. This makes them investigate, and that should reveal the bug on their side
16:34:14 <edleafe> They fix it, and everyone's happy
16:34:26 <mlavalle> I don't the cost is much
16:34:43 <cdent> edleafe: unless that tooling is on some locked down enterprisey system that can't change easily
16:35:07 <edleafe> cdent: sure, but then it's potentially a lot more serious, too
16:35:39 <cdent> but from their perspective it's been working (in a twisted sort of way)
16:35:52 <cdent> I actually agree with you though I think we should break broken code more often than we do
16:36:10 <dtantsur> heh
16:36:28 <dtantsur> well, I can imagine people passing a wrong parameter just because somebody left it there 3 years ago..
16:37:13 <elmiko> totally
16:38:11 <elmiko> mlavalle: so, has this helped? XD
16:38:35 <mlavalle> yeah, I guess we will give the user the option to keep the current behavior
16:38:44 <mlavalle> and we are going to document the change profusely
16:38:55 <mlavalle> so it becomes visible
16:39:02 <cdent> mlavalle: out of curiosity how will you control that?
16:39:26 <edleafe> mlavalle: would it be possible to default to the new behavior, with the option to specify the old behavior?
16:39:41 <mlavalle> we have the extensions mechanism in Neutron
16:39:57 <mlavalle> so I am thinking of encapsulating the new behavior in an extension
16:40:16 <mlavalle> and that's a pretty good idea edleafe :-)
16:40:35 <dtantsur> why not microversion it? :)
16:40:49 <dtantsur> I mean, if you default to new behavior, this is equivalent to removing the old completely
16:40:51 <edleafe> mlavalle: yeah, that way any new stuff written against the API will get the correct behavior
16:40:56 <elmiko> yeah, i'd think microversion > extensions, per the guidelines
16:40:58 <mlavalle> we don't handle microversions in Neutron
16:41:05 <elmiko> ah
16:41:05 <dtantsur> because if people update their software to opt-out, they can well update it to stop relying on the old behavior
16:41:14 <dtantsur> or am I missing something?
16:41:20 * cdent puts on his sales ties
16:41:49 * elmiko chuckles
16:41:50 <cdent> If there ever comes a time when you might need microversions, consider microversion-parse™ for all your microversion needs
16:41:55 <elmiko> ++
16:42:14 <mlavalle> cdent: will do....
16:42:25 <edleafe> ...and if you order now, we'll throw in this set of steak knives!
16:42:31 <mlavalle> this has been helpful
16:42:41 <mlavalle> how do I pay the $5?
16:42:48 <mlavalle> fee
16:42:50 <elmiko> edleafe: LOL
16:42:51 <cdent> canadian beer
16:42:52 <edleafe> dtantsur: well, that goes to cdent's point about we don't break stuff enough
16:43:00 <elmiko> cdent: ++
16:43:09 <edleafe> mlavalle: send me some bitcoin
16:43:21 <mlavalle> ok, I'll buy you guys a beer in Vancouver
16:43:45 <elmiko> ooh, now i have to get to vancouver!
16:43:52 * dtantsur will skip Vancouver
16:44:09 <elmiko> ok, anything else on this topic?
16:44:11 <mlavalle> or at the first ocassion I see you... how about that?
16:44:21 <mlavalle> No, I'm done, thanks
16:44:22 <elmiko> ++
16:44:26 <cdent> dtantsur: :(
16:44:31 <elmiko> thanks mlavalle for bringing this up =)
16:44:45 * edleafe will drink dtantsur's beer for him
16:44:48 <elmiko> agreed with cdent
16:44:51 <elmiko> lol
16:44:54 <elmiko> #topic weekly newsletter
16:45:01 <elmiko> #link https://etherpad.openstack.org/p/api-sig-newsletter
16:45:04 <elmiko> volunteers?
16:45:18 <cdent> I haven't done it in a while
16:45:22 <cdent> so I'm happy to do it
16:45:29 <elmiko> winner winner, chicken dinner!
16:45:32 <elmiko> thanks cdent
16:45:52 <elmiko> thanks everybody
16:45:58 <elmiko> #endmeeting