16:00:06 <elmiko> #startmeeting api sig
16:00:06 <openstack> Meeting started Thu Apr  5 16:00:06 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:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:10 <openstack> The meeting name has been set to 'api_sig'
16:00:13 <dtantsur> o/
16:00:15 <elmiko> #chair cdent elmiko edleafe dtantsur
16:00:16 <openstack> Current chairs: cdent dtantsur edleafe elmiko
16:00:18 <cdent> o/
16:00:23 <elmiko> #link https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
16:00:26 <elmiko> hey folks
16:00:29 <edleafe> \o
16:00:39 <elmiko> #topic previous meeting action items
16:01:24 <elmiko> i'm still working on a followup pr for the microversion thing
16:01:37 <elmiko> i used up my api-sig time writing the /other/ microversion thing XD
16:02:00 <elmiko> i will re-add
16:02:02 <cdent> I read that. Was comprehensible.
16:02:04 <elmiko> #action elmiko post a pr for https://review.openstack.org/#/c/444892
16:02:11 <elmiko> cool
16:02:33 <elmiko> dtantsur took care of the update to the http pr, looks nice btw
16:02:45 <elmiko> any reports from edleafe or mordred ?
16:03:26 <edleafe> I wrote to SIG ML, instead of to Melvin personally
16:03:36 <elmiko> yeah, saw that. looked good to me
16:04:10 <elmiko> #topic open mic and ongoing or new biz
16:04:11 <edleafe> Just one reply, though
16:04:18 <edleafe> besides elmiko's
16:04:23 <elmiko> #undo
16:04:24 <openstack> Removing item from minutes: #topic open mic and ongoing or new biz
16:04:37 <elmiko> was there anything from the reply?
16:04:40 <elmiko> (i missed it)
16:05:12 <edleafe> Just one person, Joe Topjian, saying that he'll be in Vancouver and would be interested in attending
16:05:23 <elmiko> ++
16:05:48 <elmiko> #topic open mic and ongoing or new biz
16:06:01 <elmiko> on the subject of Write something up for forum topics
16:06:07 <elmiko> #link http://forumtopics.openstack.org/
16:06:20 <elmiko> i don't think there is any progress here, but i am happy to be wrong =)
16:06:35 <edleafe> nuthin from me
16:06:47 <cdent> nor me
16:07:02 <elmiko> ack
16:07:08 <elmiko> so, Talk about OpenAPI stuff
16:07:16 <elmiko> #link https://gist.github.com/elmiko/7d97fef591887aa0c594c3dafad83442
16:07:18 <cdent> I think that if there's nothin super active from the SDK communitey we might skip a forum session?
16:07:25 <cdent> (the PTG is a better fit...?)
16:07:30 <elmiko> yeah, agreed
16:08:05 <elmiko> i thought maybe the forum would generate more bodies from the user/operator side of the house, was hoping that would help the x-project stuff
16:08:14 <mugsie> elmiko: on this - should the Open API represent the latest version?
16:08:24 <elmiko> mugsie: yes
16:08:37 <elmiko> i specified that in one of the paragraphs, but maybe it wasn't clear enough
16:08:40 <mugsie> latest may represent something that has not been released
16:08:50 <mugsie> no, I was questioning if that is a good idea :)
16:08:55 <elmiko> oh oh, sorry
16:09:10 <elmiko> yeah, latest would be something not released
16:09:23 <elmiko> but, the release version of the doc should be available on the release tag in the repo
16:09:29 <elmiko> is that enough to solve the issue?
16:09:32 <cdent> the api-ref is published from master though, yeah?
16:09:32 <cdent> so the documented api is not yet released either?
16:09:58 <mugsie> cdent: yeap, but it shiould have references to the microversions
16:09:59 * mordred waves
16:10:23 * elmiko waves at mordred
16:10:39 <mugsie> we may need to archive the schema on a per microversion basis - as clients don't always know the version of the software running on a cloud
16:10:49 <dtantsur> I doubt we have a standard way to represent microversions in api-ref though
16:11:01 <mugsie> all they see is a microversion, which is not easily linkjable
16:11:04 <mugsie> dtantsur: we do
16:11:16 <dtantsur> well, I mean in practice :)
16:11:24 <mordred> mugsie: yup. turns out microversions and major versions are rather similar from a consumer perspective aren't they? :)
16:11:26 <elmiko> i would hope that we could keep 1 schema with the microversions captured inside of it
16:11:36 <dtantsur> or even more precise: we in ironic don't know this way, and we've been inconsistent so far
16:11:58 <mugsie> dtantsur: it is in the doc - https://docs.openstack.org/os-api-ref/latest/usage.html#rest-parameters
16:12:14 <mugsie> gah, wrong link
16:12:14 <mugsie> https://docs.openstack.org/os-api-ref/latest/usage.html#parameters-file-format
16:12:38 <dtantsur> TIL thanks mugsie
16:12:40 <elmiko> so, i have a couple questions
16:12:46 <mugsie> mordred: yup :)
16:12:52 <dtantsur> but it's only about adding and removing, unfortunatelyt
16:12:57 <elmiko> 1. at a high level, does the approach i'm proposing make sense?
16:13:11 <elmiko> 2. if it does, is there a place to propose this to an actual repo for better discussion?
16:14:28 <mugsie> dtantsur: yeah - I think the thinking at the time was we should only remove + add, not change ?
16:14:40 <mugsie> elmiko: I think so. I need more time to digest
16:14:42 <dtantsur> mugsie: well, we do change things
16:14:45 <cdent> I would think the answer to 2 is the same place that mugsie's structure api-ref work is
16:14:48 <elmiko> mugsie: ack
16:14:51 <dtantsur> e.g. nova changed server['flavor'] quite seriously
16:15:00 <mugsie> -_-
16:15:33 <mordred> yah. I mean - I wasn't really kidding earlier when I said from a user perspective microversions are just another way to have a completely new major version
16:15:46 <mordred> just with a different selection mechanism for the call
16:15:57 <elmiko> that seems heavy to me
16:16:14 <mugsie> mordred: yeah. Part of the reason I have been a "microversions over my dead body" person in designate
16:16:18 <dtantsur> mordred: wasn't it the intention?
16:16:30 <dtantsur> lol
16:16:41 <dtantsur> mugsie: I've been there too, but somehow avoided getting dead
16:16:57 <mordred> I mean, in openstack's case it's still better than the other thing, so I'm still in favor of them
16:17:20 <cdent> I wrote much the same thing as mordred just said (about same thing) on a review recently
16:17:25 <mordred> but from an api documentation perspective thining about openapi type things, each microversion is *effectively* a whole new version of the api
16:17:26 <mugsie> dtantsur: well, one upside of being the only team member was no one could disagree with me :)
16:17:39 <cdent> it's all about the selection mechanism
16:17:44 <elmiko> mordred: yeah, that makes sense
16:17:55 <mordred> and a user looking at the documentation needs to be able to ask the question "what is the shape of the api at version 2.45"
16:18:11 <elmiko> and i guess that would be another way to go, just document each version in a separate openapi file
16:18:17 <dtantsur> mordred: true. but it's a bit different story when it comes to auto-generating SDK/CLI bits
16:18:17 <elmiko> seems excessive to me though
16:18:26 <cdent> if it could be automated, does the excess matter?
16:18:27 <mordred> that their ap  migh use version 2.45 for one call and 2.30 for a second and 2.1 for a third doesn't change the nature of it when thinking about openapi - imo
16:18:34 <elmiko> cdent: i would think not
16:18:45 <mordred> dtantsur: it's cimpletely unpossible to autogenerate an sdk based on all of the microversoins
16:19:02 <dtantsur> mordred: right, but isn't it one of the goals?
16:19:05 <elmiko> mordred: with most current tooling, i would agree
16:19:08 <dtantsur> maybe I misunderstand mugsie
16:19:09 <mordred> if it is, we should give up on it
16:19:57 <elmiko> that seems like a discussion to have with Gilles though, he is the one pushing for this automation
16:19:58 <mordred> I mean, maybe generating the low-level sdk like from dtantsur's doc - that's just doing straight pass-through
16:20:36 <edleafe> would it be possible to pick a version, and generate the low-level sdk for just that version?
16:20:44 <mugsie> does anyone know if gilles is going to YVR?
16:20:49 <mordred> but if you want an sdk that provides the high-level abstraction so that the user's aren't worried about microversions for a call, then client-side has to do data normalization
16:20:53 <elmiko> mugsie: not me
16:20:56 <edleafe> IOW, microversions give you lots of choices. Insted, make the choice and run with it.
16:21:04 <mordred> edleafe: sure - we could generate a low-level api for every microversion even
16:21:17 <edleafe> mordred: well that would be overkill, no?
16:21:20 <elmiko> mordred: that sounds like a much more small-batch hand-crafted artisanal approach XD
16:21:29 <mugsie> mordred: but your client would still have to do normalisation
16:21:32 <mordred> yes
16:21:38 <mordred> exactly
16:22:01 <elmiko> i will add a section to my doc calling out the idea of just generating an openapi schema for each version, that is a valid counter proposal
16:22:01 * dtantsur imagines a huuuuge enum of all microversions he'll have to maintain
16:22:03 <mordred> for people writing sdks that they want to work with openstack clouds _generally_ - you must support multiple versions - and if you do that, you must do client-side normalization
16:22:12 * dtantsur nopenopenopeNOPENOPENOPENOOOO
16:22:12 <mordred> dtantsur: yup
16:22:21 <mugsie> FWIW, I think we can't do reliable, automated generated clients with microversions, if you want to have a generic tool
16:22:23 <mordred> dtantsur: well - or take the approach we've been taking ...
16:22:40 * edleafe imagines dtantsur holding his breath until he gets his way
16:22:46 <elmiko> mugsie: i tend to agree, at least not without a different approach to the autogeneration
16:22:50 <mordred> dtantsur: which is to just support the base level no-microversion of the API - and then add support for specific microversions and you add support for a given feature
16:22:57 <elmiko> edleafe: LOL
16:23:14 <mordred> elmiko: which is to say - I'd honestly prefer openapi docs for the _lowest_ microversion, not the latest - as the 'default'
16:23:22 <mordred> since that's the api you get without doing any additional work
16:23:26 <mordred> so it's still "the api"
16:23:27 <mugsie> mordred: ++
16:23:49 <mordred> anything above and beyond that are essentially discoverable resource changes
16:23:52 <elmiko> mordred: interesting, so would the top level "version" field for the openapi doc represent that version?
16:23:53 <dtantsur> mordred: that's what I do now
16:23:58 <mugsie> has any project bumped the minimum version yet?
16:24:28 <dtantsur> we planned on, but then jroll left :)
16:24:31 <mordred> mugsie: not to my knowledge - although I know ironic has talked about it (why we have the next_min_version field)
16:24:44 * mordred has been pushing back as hard as he can against bumping minimums
16:25:10 <mordred> but- I think we're close to the point where I won't scream too much once someone doesit
16:25:11 <edleafe> Bumping min version == major major API version
16:25:23 <mordred> edleafe: that's been my argument all along
16:25:39 <mordred> edleafe: if you want to bump the minimum, what you've actually done is created a new major api version
16:25:57 <edleafe> zactly
16:26:01 <cdent> I thought nova sort of bumped becasue of the removal of nova-net?
16:26:05 <mordred> so if ironic were to bump the minimum to 1.6, I'd rather see the api at 1.6 become a new API called v2
16:26:19 <mordred> cdent: we're kind of giving nova a pass on the nova-net thing :)
16:26:21 <elmiko> i will take an action to reach out to Gilles and get some more information about what he needs and what might be useful. i will also show him this doc to get his input. sound good?
16:26:34 <dtantsur> mordred: it is valid in theory, but in practice will require rewriting all tooling, soooo...
16:26:37 <mordred> cdent: but no, the minimum api version has not been bumped, and 2.1 works just fine
16:26:58 <mordred> dtantsur: I know - whichis why I haven't pushed on that more
16:27:18 <edleafe> cdent: that was a "signal". IMO, a totally wrong use of microversions
16:27:42 <cdent> hmm
16:27:47 <cdent> life is weird
16:27:55 <mordred> bumping a min is great if you are only thinking about the latest release
16:28:22 <mordred> but openstack has more than one installation, so thikning only about the latest release is not a luxury api consumers get
16:28:51 <mordred> which is why "the openstack api" is actually the union of all of the major api versions and all of their microversions
16:29:13 <mordred> regardless of whether or not any given api call has been deprecated or removed in the latest release of a given service
16:29:46 <mordred> nova-net being a good case in point- it's not deprecated or removed from an api consumer/sdk perspecitve
16:30:32 * mordred feels like he brought the full negativity bomb to the meeting today!
16:30:39 <elmiko> haha
16:30:45 * edleafe wouldn't expect anything less
16:31:08 <mordred> elmiko: I love the openapi idea generally, fwiw - mostly just riffing for a minute while thinking about it
16:31:22 <elmiko> mordred: cool, and yeah it's all good =)
16:31:35 <elmiko> #action elmiko update openapi proposal with ideas from today's meeting
16:31:41 <elmiko> should i reach out to Gilles as well?
16:31:59 <cdent> when the gopher cloud people were talking about how to do microversions one of the things they said was "we need to have code for every microversion" so openstack for everything might actually be useful for them
16:32:12 <cdent> however, they hadn't yet grokked the idea of different calls gets different microversions
16:32:45 <mordred> cdent: yah - per-api-call versions are very cool - but when you start talking about strongly-typed things, those return values being different is ... fun
16:32:56 <cdent> exactly
16:33:19 <mordred> my approach so far has been to make a data structure that's returned which is the union of all of the data structures for the cal
16:33:21 <mordred> call
16:33:37 <mordred> and to fill in missing data in either direction as best as I can
16:33:58 <mordred> so that the sdk can always return the same structure, but the way it gets the data for it might change
16:34:05 <edleafe> cdent: yeah, golang is much more rigid than Python in that regard
16:34:13 <edleafe> ...and lots of other regards
16:34:16 <mordred> yah
16:34:37 <mordred> shade/sdk are trying to basically emulate the strong-typing of go/rust in the data structures returned to users
16:34:54 <mordred> so, "get_server()" should always return the same structure, regardless of API version on the remote side
16:34:54 <edleafe> elmiko: be sure to ask Gilles if he will be in YVR
16:35:21 <mordred> but it's a super big pita
16:35:43 <elmiko> edleafe: ack
16:36:01 <elmiko> #action elmiko reach out to Gilles to discuss openapi stuff and gauge presence at YVR
16:36:34 <elmiko> mordred: given what we've enabled with microversions, that seems daunting
16:36:54 <elmiko> ok, anything else we should discuss on this topic?
16:37:05 <elmiko> or any other open mic business?
16:37:36 <elmiko> if any of you do have comments on the doc i posted, please just add comments to the gist, i will capture them for the next version
16:37:54 <elmiko> #topic guidelines
16:38:01 <elmiko> #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
16:38:08 <elmiko> #link https://review.openstack.org/#/q/status:open+project:openstack/api-sig,n,z
16:38:20 <elmiko> the only one i really looked at here was dtantsur's
16:38:22 * mordred has started working on discover/version things in keystoneauth again this morning ... so should be getting back to his specs in the nex day or so
16:38:37 <elmiko> mordred++
16:39:03 <elmiko> should we move to freeze, https://review.openstack.org/#/c/554921/ ?
16:39:40 <edleafe> sure - you want the honor?
16:39:52 <elmiko> sure
16:40:29 <elmiko> done
16:41:16 * mordred loves that patch
16:41:20 <elmiko> any other reviews folks want to highlight?
16:41:39 <dtantsur> the http split thingy?
16:41:58 <edleafe> yeah - I like the way dtantsur updated to add the doctree
16:42:05 <dtantsur> #link https://review.openstack.org/554234
16:42:08 <elmiko> yeah, lgtm, do we need a freeze for that or just get more +1s then merge?
16:42:18 <dtantsur> elmiko: it does not have new text, right?
16:42:25 <edleafe> I'd prefer to get more eyes on it
16:42:26 <elmiko> didn't look like it to me
16:42:44 <edleafe> No significant new text
16:42:59 <elmiko> so, everyone go review that and test it =)
16:43:09 <elmiko> #action everyone go review https://review.openstack.org/#/c/554234/
16:44:04 <elmiko> #topic bug review
16:44:12 <elmiko> #link https://bugs.launchpad.net/openstack-api-wg/+bugs?orderby=-id&start=0
16:44:18 <elmiko> #link https://bugs.launchpad.net/openstack-api-sig/+bugs?orderby=-id&start=0
16:44:21 <elmiko> anything new here?
16:45:37 <dtantsur> yep, I filed one idea
16:45:40 <elmiko> in fact, yes
16:45:44 <elmiko> #link https://bugs.launchpad.net/openstack-api-wg/+bug/1761475
16:45:45 <openstack> Launchpad bug 1761475 in openstack-api-sig "[RFC] Add "severity" to the error structure" [Undecided,New]
16:46:04 <dtantsur> I don't insist on it, just came out of review of one our spec
16:46:10 <dtantsur> fwiw I agree with cdent's concerns
16:46:10 <elmiko> so, given cdent's feedback, this seems debatable
16:46:34 <elmiko> should we triage as wishlist or drop it?
16:46:37 <dtantsur> but I had to at least propose it for discussion
16:46:51 <elmiko> yeah for sure
16:46:53 <dtantsur> edleafe, elmiko, what do you think about the idea?
16:47:25 <edleafe> it does seem wishlist at best
16:47:39 <edleafe> I'd be inclined to agree with cdent on this
16:47:40 <elmiko> i'd be ok with making it an optional guideline, but at that point i kinda agree with cdent, seems onerous for deves
16:47:56 <elmiko> so, yeah, maybe mark as triaged and wishlist?
16:48:01 <edleafe> +1
16:48:07 <elmiko> unless cdent is a hard -1?
16:48:37 * cdent tries to catch up
16:48:46 <elmiko> we got time
16:49:18 <cdent> I'm not hard -1, but I think wishlist provides a level of approval that I haven't got, but wouldn't want to fight the majority
16:50:01 <dtantsur> with edleafe -0 (right?) I think it should go to Opinion
16:50:03 <elmiko> yeah, fair cdent
16:50:38 <edleafe> yeah, "wishlist" => "I wish we could do this"
16:50:48 <elmiko> so maybe, triaged/undecided then?
16:50:56 <dtantsur> this is what Opinion is about
16:51:01 <edleafe> I'm closer to -1
16:51:11 <dtantsur> "Does not fit, may be revisited"
16:51:19 <dtantsur> undecided means untriaged :)
16:51:29 * dtantsur has spent a lot of time triaging bugs for ironic
16:51:32 <cdent> weren't we going to move to storyboard or something :)
16:51:35 <elmiko> dtantsur: fair
16:51:49 <dtantsur> cdent: good question
16:52:02 <dtantsur> actually, we could benefit from storyboard a lot
16:52:10 <edleafe> more like "Won't Fix" IMO
16:52:11 <dtantsur> we could create tasks for different projects under one story
16:52:23 <dtantsur> edleafe: whatever :D
16:52:58 <dtantsur> wontfix means 'never for sure', opinion means 'if you spend really a lot of time convincing us'
16:53:18 <elmiko> #vote should bug #1761475 be marked won't fix?
16:53:19 <openstack> bug 1761475 in openstack-api-sig "[RFC] Add "severity" to the error structure" [Undecided,New] https://launchpad.net/bugs/1761475
16:53:33 <elmiko> did i do that wrong?
16:53:48 <cdent> i think you have to start it?
16:53:49 <cdent> #help
16:53:51 <dtantsur> elmiko: it's startvote
16:53:55 <dtantsur> I can do it
16:53:55 <elmiko> ahh, cool
16:53:57 <elmiko> thanks
16:54:05 * cdent wonders why help doesn't. that would be nice.
16:54:14 <dtantsur> #startvote Should we mark bug #1761475 as WONTFIX? Yes, No
16:54:15 <openstack> Begin voting on: Should we mark bug #1761475 as WONTFIX? Valid vote options are Yes, No.
16:54:16 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
16:54:25 <dtantsur> #vote Yes
16:54:40 <edleafe> #vote Yes
16:54:47 <cdent> #vote yes
16:54:51 <cdent> because hide the noise
16:55:02 <elmiko> #vote yes
16:55:03 <dtantsur> note that Opinion is also a closed state
16:55:11 <dtantsur> anyone else to vote?
16:55:15 * edleafe wonders about case-sensitivity in the votes
16:55:22 <dtantsur> edleafe: it's not case-sensitive
16:55:29 * cdent wonders how many sheds there are
16:55:30 <dtantsur> and it errors out if you try something wrong
16:55:31 <elmiko> seems like won't fix
16:55:34 <dtantsur> #vote booo
16:55:35 <openstack> dtantsur: booo is not a valid option. Valid options are Yes, No.
16:55:38 <dtantsur> see?
16:55:39 <dtantsur> #endvote
16:55:40 <openstack> Voted on "Should we mark bug #1761475 as WONTFIX?" Results are
16:55:41 <openstack> Yes (4): cdent, dtantsur, edleafe, elmiko
16:55:45 <edleafe> cool
16:55:58 <edleafe> done
16:55:59 * dtantsur was a PTL for 2 cycles
16:56:09 <elmiko> ok, then
16:56:17 <elmiko> #topic weekly newsletter
16:56:23 <elmiko> #link https://etherpad.openstack.org/p/api-sig-newsletter
16:56:26 <elmiko> volunteers?
16:56:51 <cdent> i was last time, so not me
16:57:02 <elmiko> ack, i can take it if folks are busy
16:57:08 <edleafe> I would, but I have to run out right after this
16:57:15 <elmiko> fair
16:57:24 <elmiko> ok then, i'll ping in sdks when it's ready
16:57:27 <cdent> thanks
16:57:29 <dtantsur> thanks
16:57:30 <edleafe> so don't wait around for my ack
16:57:37 <elmiko> thanks for the good discussions all =)
16:57:44 <elmiko> #endmeeting