16:00:11 <elmiko> #startmeeting api sig
16:00:12 <openstack> Meeting started Thu Mar 29 16:00:11 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:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:15 <openstack> The meeting name has been set to 'api_sig'
16:00:20 <elmiko> #chair cdent elmiko edleafe dtantsur
16:00:21 <openstack> Warning: Nick not in channel: cdent
16:00:22 <openstack> Current chairs: cdent dtantsur edleafe elmiko
16:00:40 <elmiko> #link https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
16:00:57 <cdent> o/
16:00:59 <edleafe> \o
16:01:03 <cdent> tc is navel gazing
16:01:23 <elmiko> omphaloskepsis, my favorite past time =)
16:02:16 <elmiko> #topic previous meeting action items
16:02:23 <elmiko> #link http://eavesdrop.openstack.org/meetings/api_sig/2018/
16:02:52 <elmiko> so, i reviewed 444892 and added my comments on the review
16:03:07 <cdent> saw that, how should we proceed?
16:03:38 <elmiko> i think it would be cool to fix up the doc, add the missing material, and then have it link off the microversion guideline with a "read some history" type note
16:03:56 <elmiko> it's certainly not a guideline, but it is an interesting read imo
16:04:20 <cdent> It could help people to get to the more basic why of it, rather than just because "openstack says so"
16:04:25 <elmiko> right
16:04:46 <elmiko> that's kinda why i think it would be cool to have a link at the top of the microversion guideline to it
16:05:06 <elmiko> clearly warning the reader that it is editorial/history and not guideline
16:05:33 <cdent> yeah
16:05:44 <cdent> are you volunteering or do you want to pass the ball?
16:05:46 <edleafe> That was my impression, too
16:06:04 <edleafe> Not a guideline at all
16:06:07 <elmiko> i could help fix it up, but i'm not sure i have the context for the one section where Sean mentioned diagrams
16:06:14 <elmiko> that didn't make sense to me right away
16:07:01 <cdent> I've also reviewed a presentation where sean used similar diagrams and I think he's mental modelling in his own way (from the inside) that might be a blocker, so it might make sense to keep the idea of diagrams, but different ones
16:07:08 <dtantsur> o/ (sorry, forgot)
16:07:17 <elmiko> fair
16:07:45 <elmiko> i guess i need to understand the issue about adding fields a little better as well
16:08:13 <edleafe> it should live in /doc, not /guidelines, right?
16:08:37 <elmiko> hmm, yeah, that makes more sense
16:09:22 <elmiko> i don't mind taking a whack at the first rework on that
16:10:37 <elmiko> #action elmiko post a pr for https://review.openstack.org/#/c/444892
16:11:13 <cdent> yay!
16:11:15 <elmiko> we might want to engage mordred for his thoughts on the SDKs and Client Applications sections
16:11:40 <elmiko> i guess we can work it out through the review process though
16:12:10 * mordred has time to spend on things again!
16:12:16 <elmiko> \o/
16:12:39 <elmiko> mordred: any suggestions you have on that pr up there are greatly appreciated =)
16:13:20 <mordred> kk
16:13:31 <elmiko> thanks!
16:13:39 <dtantsur> mordred++
16:13:46 <mordred> (I mean, other than my suggestions for alternate names)
16:13:56 <elmiko> yes, please XD
16:14:23 <elmiko> were those name suggestions serious, i am not in the know enough to get the references
16:14:38 <elmiko> i thought you /might/ be joking, but couldn't tell
16:15:05 <mordred> elmiko: honestly, I'm not sure _I_ know
16:15:16 <elmiko> hahaha, well played sir
16:15:42 <elmiko> the only other action item was for edleafe, i think that was completed as well
16:16:17 <elmiko> #topic open mic and ongoing or new biz
16:16:25 <elmiko> Write something up for forum topics:
16:16:31 <elmiko> #link http://forumtopics.openstack.org/
16:16:48 <elmiko> so, who is going to forum?
16:16:51 <cdent> we don't specifically need to do anything at the forum, but if we want to, that's the place to start something
16:16:52 <cdent> me
16:17:02 <edleafe> I'll be there
16:17:17 <elmiko> ahh, gotcha
16:17:18 * mordred will be there
16:17:28 <elmiko> i won't be there, do you folks want to host any topics?
16:17:36 <edleafe> We can see if there is any interest in a x-proj with SDK folks
16:17:48 <elmiko> ++
16:17:49 * edleafe wants to keep trying to draw them in
16:17:51 <mordred> I havea topic related to dtantsur's microversion spec - and a patch we got over in openstacksdk land ...
16:17:55 <elmiko> that sounds great to me edleafe
16:17:57 <cdent> that's a good idea
16:18:07 * dtantsur is not going
16:18:07 <mordred> (although it's slighly more specific perhaps)
16:18:27 <elmiko> mordred: ok, let's pick that up next
16:18:41 <mordred> elmiko: sweet, thanks
16:18:59 <elmiko> so edleafe or cdent, does one of you want to add something for forum then?
16:19:10 <elmiko> or i guess talk to the sdk folks?
16:20:15 <edleafe> not sure. Maybe I could ping Melvin, since he was an original mover for this?
16:20:22 <elmiko> sounds good to me
16:21:43 <elmiko> #action edleafe reach out to Melvin about potential sdk cross project topic for forum
16:21:43 <edleafe> #action edleafe to ping Melvin Hillsman about a joint SDK/API-SIG meeting at the Forum
16:21:46 <elmiko> haha
16:21:52 <edleafe> #undo
16:21:52 <openstack> Removing item from minutes: #action edleafe to ping Melvin Hillsman about a joint SDK/API-SIG meeting at the Forum
16:22:23 <elmiko> anything else on this before we turn the floor over to mordred ?
16:22:27 <dtantsur> maybe if we leave two action items on edleafe, he'll double the effort?
16:22:34 * elmiko chuckles
16:22:43 <mordred> dtantsur: ++
16:23:00 <elmiko> alright then, the floor is yours mordred
16:23:07 <edleafe> dtantsur: nah, I'll just send Melvin two copies of the same email
16:23:26 <dtantsur> lol
16:24:13 <mordred> it seems in some places people have been re-using the api version setting (like OS_COMPUTE_API_VERSION)
16:24:14 <mordred> to set what keystoneauth/openstacksdk consider 'default_microversion'
16:24:16 <mordred> in keystoneauth we distinguish the two - api_version means major api version and microversion/default_microversion means microversion
16:24:18 <mordred> so on the one hand I'd sort of prefer to _not_ take OS_COMPUTE_API_VERSION and have it set a default microversion
16:24:20 <mordred> but on the other hand it's easy enough to say "if '.' in OS_COMPUTE_API_VERSION: default_microversion=OS_COMPUTE_API_VERSION"
16:24:34 <mordred> what do people think the right thing to do is?
16:24:53 <dtantsur> is it about CLI or SDK?
16:25:07 <dtantsur> I'm pretty sure we do OS_BAREMETAL_API_VERSION in CLI (but not in the SDK)
16:25:09 <mordred> dtantsur: same config source - so it needs to behave the same in both
16:25:38 <dtantsur> I may not understand what you mean by "same config source"
16:25:53 <dtantsur> maybe because I don't know openstacksdk
16:25:55 <mordred> well, a human can have baremetal_api_version set in clouds.yaml
16:25:59 <elmiko> i kinda like not using OS_COMPUTE_API_VERSION as the default, but if this is easier for actual users then maybe we should consider the other
16:26:03 <mordred> and that will get used by openstacksdk and by osc
16:26:14 <dtantsur> right
16:26:32 <dtantsur> so again, what's the problem? you don't want people to use it for <...>?
16:26:37 <mordred> well, more specifically, it'll be used by os_client_config/openstack.config to create the keystoneauth adapters in question
16:26:50 <mordred> dtantsur: the main issue is that currently the behavior is undefined
16:27:10 <mordred> people using python-*client have one behavior expectation that we *can* choose to behave the same as
16:27:35 <mordred> or we could say "f you want to configure a default microversion, use OS_BAREMETAL_DEFAULT_MICROVERSION / baremetal_default_microversion
16:27:52 <dtantsur> omg
16:27:55 <mordred> it's really a question of what to do if someone sets OS_COMPUTE_API_VERSION=2.45
16:28:10 <dtantsur> this is the microversion (and that's what we do in ironic's OSC plugin btw)
16:28:26 <dtantsur> people will rightfully hate us for too many options doing seemingly the same thing
16:28:38 <edleafe> dtantsur: ++
16:28:43 <dtantsur> especially, if the major version configuration will differ from major version of a microversion (what am I saying?)
16:28:47 <elmiko> yeah, agreed dtantsur
16:28:50 <mordred> dtantsur: ok. so you're in favor of feeding 2.45 into default_microversion if we find a versoin of such a form
16:28:59 <dtantsur> mordred: very strongly in favor, yes
16:29:16 <mordred> kk
16:29:32 <elmiko> sweet
16:29:41 <dtantsur> it would be a different story if we did not include a major version in a microversion :D
16:29:43 <elmiko> anything more on this, like do we need a guideline?
16:30:04 <dtantsur> elmiko: since we already have one guideline proposed targeting SDKs, why not have moar?
16:30:33 <mordred> _maybe_ we need to say something in dtantsur's guideline about how to deal with api_version env/config as it relates to the options?
16:30:34 <elmiko> i was just curious if we need a new doc, or can we add this on to the microversion stuff that currently exists?
16:30:43 <cdent> If there's documentation for clouds.yaml I don't think we should duplicate that
16:30:47 <elmiko> yeah, mordred, that's kinda what i was wondering
16:30:57 <dtantsur> mordred: sure, but maybe as a follow-up (simply not to unfreeze it just for it)
16:31:06 <elmiko> dtantsur: ++
16:31:09 <mordred> ++
16:31:22 <mordred> dtantsur: although I *was* going to quibble about the example parameter names ...
16:31:25 <elmiko> so, that last question, who wants to write that follow up?
16:31:32 <mordred> but I thinkn that can also go into a followup
16:31:39 <mordred> since they're just examples
16:31:44 <dtantsur> mordred: this is going to be a fun conversation ;)
16:31:48 <elmiko> lol
16:31:49 <mordred> dtantsur: :)
16:32:00 <edleafe> elmiko: sounds like mordred just volunteered :)
16:32:07 <mordred> dtantsur: mainly just we already have parameter names in openstacksdk/keystoneauth and they are not what is used in the examples
16:32:07 <elmiko> \o/
16:32:13 <mordred> elmiko: yah. I can do the followup(s)
16:32:18 <elmiko> thanks mordred !
16:32:22 <dtantsur> cool
16:32:41 <elmiko> #action mordred right followup guidance of microversions in default config values
16:32:48 <elmiko> does that make sense?
16:32:57 <elmiko> oh wait
16:32:59 <elmiko> #undo
16:33:00 <openstack> Removing item from minutes: #action mordred right followup guidance of microversions in default config values
16:33:10 <elmiko> #action mordred write followup guidance of microversions in default config values
16:33:13 <elmiko> hehe
16:33:15 <mordred> hahaha
16:33:31 <elmiko> *now* does it make sense?
16:33:35 <edleafe> right wasn't right
16:33:39 <elmiko> lol
16:33:43 <dtantsur> hehe
16:33:58 <elmiko> cut me some slack, i'm going on pto in 30 minutes XD
16:34:28 <elmiko> ok, so i have a quick update re: os-api-ref and mugsie's work
16:34:56 <elmiko> i've been studying the options and i think i have an idea about how we can use openapi to capture our schemas, even with microversions
16:35:03 * mugsie perks up
16:35:22 <elmiko> i need to do a little more research, but i would like to propose a doc about this and maybe we can incorporate into the output pr for os-api-ref
16:35:44 <elmiko> basically, i think we can use some of the extension mechanics in openapi to give us visibility into historical microversions
16:36:17 <elmiko> the main openapi schema would define the current version of an api, with microversions in the extensions
16:36:30 <mugsie> elmiko: cool. if we can get an end game for the schema, I can look at fixing the review
16:36:53 <elmiko> mugsie: sweet, i will put more time into writing this up, perhaps next week or the following i will have it done
16:37:22 <elmiko> the net upside is the we could use current openapi tooling to process a "master" version of any api
16:37:30 <dtantsur> that may work
16:37:42 <elmiko> the down side is that someone would need to make tooling that could ingest the microversions, but this won't be too bad
16:37:46 <dtantsur> though I'm not sure if the extensions can express e.g. a field changing its type and semantics
16:37:48 <elmiko> and might help Gilles situation as well
16:37:53 <dtantsur> (think, server's flavor)
16:38:08 <elmiko> dtantsur: i _think_ it can, but i am not quite done with my investigation yet
16:38:42 <elmiko> basically, i'm pretty sure there is a way to capture entire path object trees and that would go a long way to helping with big changes
16:39:06 <elmiko> we could then use definitions and extension mechanics to carry other bits as needed
16:39:16 <elmiko> i will write this all up though
16:39:35 <dtantsur> cool, elmiko++
16:39:55 <elmiko> that's all from me
16:40:04 <elmiko> anything else for open mic?
16:40:39 <elmiko> #topic guidelines
16:40:47 <elmiko> #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
16:40:54 <elmiko> #link https://review.openstack.org/#/q/status:open+project:openstack/api-sig,n,z
16:41:05 <edleafe> I just answered dtantsur's comment on the HTTP refactor
16:41:09 <elmiko> so, we get to merge dtantsur's =)
16:41:14 <elmiko> or do we?
16:41:34 <edleafe> Basically, I don't know enough about Sphinx to get any fancier than it currently is
16:42:03 <dtantsur> edleafe: I can help you with sphinx-foo, but I'm out till Tue
16:42:10 <elmiko> dtantsur, do you want to take a shot at prettyfying it ?
16:42:18 <dtantsur> elmiko: totally, but see ^^^
16:42:21 <elmiko> yup
16:42:25 <edleafe> dtantsur: that's ok, I guess it's time I learned
16:42:34 <edleafe> :)
16:42:40 <elmiko> #action dtantsur help to make https://review.openstack.org/#/c/554234/ purty
16:42:46 <dtantsur> purrrr
16:42:50 <elmiko> hehe =)
16:42:59 <edleafe> let me take first crack at it
16:43:14 <elmiko> and i'm guessing we are merging https://review.openstack.org/#/c/532814/ ?
16:43:25 <elmiko> edleafe you wanna take the honors on that
16:43:31 <edleafe> sure!
16:43:41 <edleafe> +W'd
16:44:02 <elmiko> i guess we can address Akihiro's issues on a followup, but he didn't -1
16:44:05 <dtantsur> \o/
16:44:21 <dtantsur> yeah, when people +1 I assume they're fine
16:44:28 <cdent> my two proposals look like they need some review
16:44:41 <edleafe> follow-ups are always good
16:44:42 <elmiko> yeah, and there is still the larger question on https://review.openstack.org/#/c/554921/
16:44:52 <elmiko> like, do we want type in there
16:45:10 <elmiko> originally i liked your proposal cdent, but after you made me think about it more i am not so sure
16:45:36 <cdent> Yeah, I wanted to make people think
16:45:48 <cdent> however, if mordred is still around he probably has a strong opinion
16:46:18 <elmiko> my only objection would be if there were ever a situation where 2 different named services could fill the same type, then the errors might not be as specific as necessary
16:46:25 <elmiko> but that might be over paranoid on my part
16:46:48 <cdent> thei idea is that that's not suposed to happen
16:46:49 <edleafe> cdent: Perhaps a bit meatier commit message would help others understand your thinking
16:46:55 <mordred> cdent: I alwayshave a strong opinion
16:47:20 <cdent> edleafe: I was trying to leave it open for the sake of people finding their own way
16:47:22 <edleafe> mordred: wow, you're fast
16:47:24 <mordred> cdent: yes to service-typeplease, if that's the quesiton
16:47:31 <cdent> mordred: yes
16:47:49 <edleafe> cdent: you realize that most people will just get lost :)
16:48:15 <cdent> I guess I thought people would read the bug
16:48:19 <mordred> if two differently named services fill the same type and do not return the same named errors for error conditions, then something is horribly broken
16:48:21 * cdent is ever in hope
16:48:33 <mordred> as users of the service would have no way of knowing how to deal with the api
16:49:26 <elmiko> that makes some sense to me mordred, i was trying to think of weird scenarios where type might not be sufficient
16:49:40 <elmiko> but maybe those scenarios don't really make sense
16:49:51 <mordred> elmiko: they probalby exist - but are all evil :)
16:49:57 <elmiko> hahaha, fair
16:50:13 <dtantsur> I'm with mordred on this one
16:50:16 <cdent> I knew mordred would stand for this one
16:50:22 <elmiko> ok, cool
16:50:33 <elmiko> 10 minutes left, anything else on the guidelines?
16:51:04 <edleafe> not from me
16:51:07 <elmiko> #topic bug review
16:51:13 <elmiko> #link https://bugs.launchpad.net/openstack-api-wg/+bugs?orderby=-id&start=0
16:51:20 <elmiko> #link https://bugs.launchpad.net/openstack-api-sig/+bugs?orderby=-id&start=0
16:51:43 <elmiko> don't think there is anything new here
16:51:46 <cdent> nope
16:52:11 <elmiko> seems like we should mark this up though, https://bugs.launchpad.net/openstack-api-wg/+bug/1756464
16:52:13 <openstack> Launchpad bug 1756464 in openstack-api-sig "Errors guidelines reference service name, should be type" [Undecided,New]
16:52:17 <elmiko> if everyone agrees it is a bug
16:52:38 <cdent> seems so
16:52:42 <edleafe> +1
16:53:05 <elmiko> ok, updated
16:53:06 <cdent> our hookup for autoginning the hookup with patches doesn't seem reliable
16:54:22 <elmiko> if you say so
16:54:39 <elmiko> it took me like 4 reads to get that
16:54:41 <elmiko> hehe
16:54:54 <elmiko> #topic weekly newsletter
16:54:54 <cdent> i'm well past the number of hours and brains I should have used this week
16:55:02 <elmiko> LOL, inorite?
16:55:08 <elmiko> #link https://etherpad.openstack.org/p/api-sig-newsletter
16:55:20 <elmiko> as noted earlier i am going on pto shortly, any volunteers?
16:55:37 * cdent taps foot
16:55:38 <cdent> oh fine
16:55:41 <cdent> :)
16:55:41 <elmiko> hahaha
16:55:51 <elmiko> thanks cdent
16:55:57 <cdent> you going away, or just off?
16:56:09 <elmiko> just off, wife and i are spending some quality time around town
16:56:17 <edleafe> noice
16:56:21 <cdent> very nice
16:56:21 <elmiko> =)
16:56:34 <elmiko> hope y'all have a nice weekend as well!
16:56:49 <elmiko> #endmeeting