16:00:05 <etoews> #startmeeting api wg
16:00:05 <openstack> Meeting started Thu Jan 28 16:00:05 2016 UTC and is due to finish in 60 minutes.  The chair is etoews. 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:09 <openstack> The meeting name has been set to 'api_wg'
16:00:21 <etoews> hola
16:00:35 <rosmaita> o/
16:01:10 <elmiko> yo/
16:01:34 <cdent> o/
16:02:16 <etoews> #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
16:02:35 <etoews> ummmm...not so many updates from last week.
16:02:52 <elmiko> we've got a couple new guidelines that have been proposed =)
16:02:58 <elmiko> nice to see the activity
16:03:04 <etoews> yes!
16:03:08 <etoews> #topic previous meeting action items
16:03:19 <etoews> #link http://eavesdrop.openstack.org/meetings/api_wg/2016/api_wg.2016-01-14-16.00.html
16:03:41 * etoews assumes nothing happened at last week's meeting...
16:03:49 <cdent> "cdent to re-review https://review.openstack.org/#/c/234994/ with an eye to reaching consensus" FAIL
16:03:52 <elmiko> i got word through ryanb that miguel is cool with me taking over the actions review
16:04:07 <elmiko> and i froze that review, but it got pinged and sent back to review :/
16:04:09 <cdent> sorry about making that harder
16:04:18 <elmiko> haha
16:04:27 <etoews> elmiko: good on you for taking that on
16:04:37 <elmiko> no worries, there are some good suggestions in the comments cdent
16:04:50 <elmiko> etoews: i feel it's gonna be rough slough
16:05:31 <cdent> I think splitting it in two is a good way to go.
16:05:57 <cdent> changing some thing's state v doing some stuff
16:06:09 <elmiko> good idea
16:06:23 <etoews> ya. we need to start finding alternative ways to make progress on this stuff.
16:06:28 <elmiko> and there is the whole issue of whether tasks/actions/workflows should even be separate resources
16:07:00 <elmiko> is it even possible for us to start smaller on some of the more controversial guidelines?
16:07:20 <etoews> i think it's worthwhile to try
16:07:21 <elmiko> i like the approach that ken o'omichi took with the microversion stuff
16:07:43 <elmiko> (i think it was him)
16:07:48 <etoews> i wish i had done something like that with the errors guideline
16:08:11 * cdent sings there's always tomorrow...
16:08:19 <elmiko> ok, given that, i'll try to break the "actions" guideline up into more manageable pieces
16:08:34 <ameade> o/
16:08:37 <etoews> it almost became a true ocean boiling guideline but i had to cut it off with a todo before it got way out of hand
16:09:01 <rosmaita> ameade: \o
16:09:21 <etoews> anyhoo
16:09:22 <etoews> #topic api wg cfp for openstack summit in austin
16:09:34 <etoews> #link https://etherpad.openstack.org/p/austin-api-wg-session-plans
16:10:08 <etoews> i'm all for slapping that agenda into the submission for and pushing go
16:10:42 <elmiko> i have been meaning to add little to that agenda, but i keep failing =(
16:11:03 <cdent> will that satisfy whatever filters they are using (if any) or do we get a slot just by virtue of being a real working group?
16:11:12 <etoews> elmiko: cdent: either of you care to make the submission (with the others as co-speakers)?
16:11:14 <elmiko> i think we should have an item to discuss fairy-slipper, and i do want to give a presentation on the example project idea i've been working on
16:11:40 <etoews> sgtm
16:11:41 <cdent> i think elmiko just volunteered
16:11:50 <elmiko> fair, i'm cool with that
16:11:54 <cdent> :)
16:12:04 <elmiko> #action elmiko to post api-wg submission for austin summit
16:12:24 <etoews> cdent: for the first time in a long time on not a chair on any of the tracks so i'm not sure
16:12:31 <etoews> but i expect so
16:13:02 <elmiko> i can try to spice it up a little for the descriptive entry if you think it's necessary?
16:13:14 <etoews> i could reach out and find out who the wg track chairs are and see what's really necessary
16:13:35 <cdent> maybe a little paragraph saying "we're going to do some stuff" and then top level agenda items as a list
16:13:43 <elmiko> cdent: yea, i like that
16:14:01 <etoews> sgtm
16:14:27 <etoews> #action etoews to try to find out just how much hoop jumping we need to do for the wg submission
16:14:56 <cdent> has to be done my monday, yeah?
16:15:09 <etoews> yes. that work for you elmiko ?
16:15:30 <elmiko> etoews: yup, i'll have something ready to go
16:15:40 <etoews> i'm around all day today and tomorrow so don't hesitate to ping.
16:15:49 <elmiko> just ping me with an email or something if you get word about the hoop jumping
16:15:56 <elmiko> cool
16:16:02 <etoews> yep
16:16:19 <etoews> #topic magnum api refresh
16:16:39 <etoews> #link https://blueprints.launchpad.net/magnum/+spec/standardised-error-messages
16:16:54 <cdent> that's nice
16:16:55 <etoews> so this is a holdover topic from last week but that ^ makes me smile
16:17:17 <elmiko> ooh, neat
16:17:18 <etoews> what i need to do is reach out to the magnum CPLs and highlight that for them
16:17:47 <elmiko> +1
16:17:58 <etoews> #action etoews to reach out to the magnum CPLs and highlight https://blueprints.launchpad.net/magnum/+spec/standardised-error-messages for them
16:18:41 <etoews> i also know magnum's mid-cycle is coming up and some api changes might fall out of that
16:19:15 <etoews> is there a prescribed mechanism for making part of an api a "plugin"?
16:19:29 <etoews> i know the whole extension thing was a miserable failure in nova.
16:19:39 <rosmaita> + 1000
16:19:42 <cdent> etoews: do you mean optional?
16:19:46 <etoews> yes
16:19:50 <elmiko> i'm not aware of anything from the rest api side, just the stevedore stuff from the code api
16:19:53 <agentleweb> the model I think of as best for users is LBaaS in neutron, anyone else?
16:20:11 <agentleweb> where it's another endpoint/use case
16:20:36 <cdent> endpoints seem to be the hammer for most things like this
16:20:40 <etoews> agentleweb: do you have a link to something that describes exactly how the optional aspect of that works?
16:20:53 <etoews> cdent: can you expand on that a bit?
16:20:55 <cdent> so as to avoid a situation where something the service catalog is consistent between clouds
16:21:13 <cdent> s/the/in the/
16:21:20 <agentleweb> etoews: hm, thinking
16:21:25 <cdent> so if something is optional, then it just isn't in the service catalog when it is not available
16:21:55 <cdent> that may, however, be a too broad hammer
16:21:56 <etoews> cdent: do you mean s/consistent/inconsistent/ above?
16:22:11 <cdent> sigh, yeah
16:22:27 <cdent> or s/avoid/ensure/, your choice
16:22:44 <etoews> that is a broad hammer but at least it's another option. a reasonably well understood option at that.
16:23:07 <cdent> ceilometer has a capabilities api
16:23:11 <etoews> although "avoid a situation where something the service catalog is consistent" is pretty accurate :P
16:23:45 <cdent> which basically says something to the effect of "are events turned on" and the like
16:23:58 <cdent> but I'm not sure that's a pattern used elsehwere
16:24:10 <cdent> and not something I would want to encourage in services
16:24:14 <agentleweb> cdent: yeah that's used in swift as well but let me think of the name
16:24:25 <cdent> I think they should be whatever they are and just do what they do
16:24:28 <etoews> cdent: do you have a link to something that describes exactly how the optional aspect of the capability api works?
16:24:35 * cdent looks
16:24:49 <agentleweb> ah, but it's GET /info
16:25:05 <cdent> etoews: this good enough: http://docs.openstack.org/developer/ceilometer/webapi/v2.html#capabilities
16:25:25 <elmiko> cdent: is that a discovery mechanism for the extensions?
16:25:30 <cdent> one of the drivers of that was tempest (which then ended up not using it)
16:25:33 <agentleweb> etoews: also swift http://blogs.rdoproject.org/6509/swift-discoverable-capabilities
16:25:48 <cdent> elmiko: it's discovery of what the storage system behind the api is able to do
16:25:59 <elmiko> ah, ok
16:26:16 <agentleweb> etoews: and http://docs.openstack.org/developer/swift/api/discoverability.html
16:26:28 <elmiko> seems like doing something akin to json-home would work well for discovering the extension endpoints (assuming we are talking api extensions)
16:26:34 <agentleweb> yeah it's about what's implemented
16:27:06 <etoews> "To discover which features are enabled in your Object Storage system, use the /info request. However, your service provider might have disabled the /info request"
16:27:07 <etoews> LOL
16:27:17 <elmiko> ouch
16:27:41 <cdent> that topic came up here (nova mid-cycle) today. providers sometimes turn off discovery
16:27:59 <cdent> (of all sorts)
16:28:16 * etoews sighs
16:28:29 <agentleweb> yeah that too... sigh
16:28:39 <agentleweb> those darn providers :)
16:29:09 <cdent> I think moving in the direction of json-home would be a GoodThing™
16:29:14 <etoews> okay. this is all good info (pun intended). i'll feed this back to the magnum team.
16:29:26 <elmiko> lol
16:29:55 <etoews> #action give feedback to magnum team on ways to do "optional" parts of an api
16:30:02 <elmiko> the whole provider thing does bring up an interesting point about enabling/disabling discovery mechanisms though
16:30:02 <cdent> Basically I think we should strive to do things in the direction of the rest of the world...
16:30:11 <etoews> #action etoews give feedback to magnum team on ways to do "optional" parts of an api
16:30:37 <etoews> did jsonhome ever really get any traction?
16:31:04 <etoews> not that i think it's a bad idea but it would be nice to be able to point to successful use cases outside of openstack-land
16:31:11 <agentleweb> no I haven't seen it etoews
16:31:12 <rosmaita> etoews: that's what i'm wondering
16:31:19 <elmiko> etoews: +1
16:31:21 <rosmaita> i haven't seen it anywhere
16:31:29 <rosmaita> except maybe keystone
16:31:31 <cdent> I can check with some out there in the rest of the world contacts
16:31:37 <etoews> let me ping some of the api-heads i know. see if they're aware of it.
16:31:43 <elmiko> did json-home make it out of drafting yet?
16:31:48 <etoews> nope
16:31:53 <elmiko> thought so
16:31:55 <rosmaita> no, and last draft expired 2013
16:32:02 <elmiko> ooph
16:32:06 <cdent> feh
16:32:11 <agentleweb> yah
16:32:16 <etoews> nab
16:32:28 * cdent is not wed to json-home, just want something that is not openstack-specific-special-flower-magic
16:32:43 <rosmaita> cdent: i hear you
16:32:50 <etoews> yep. that's the direction i usually lean too.
16:33:12 <agentleweb> cdent: ++
16:33:27 <elmiko> nah, we definitely need our own impl for this... s/
16:33:34 <cdent> /kick elmiko
16:33:39 <elmiko> haha
16:33:45 <etoews> #action etoews reach out to api-heads to see if jsonhome ever got traction anywhere
16:33:48 <elmiko> come-on, i know you love a contrarian ;)
16:33:58 <cdent> It's true <3
16:34:33 <etoews> any other new topics people want to discuss or move onto guidelines?
16:34:45 <cdent> onward
16:34:59 <etoews> #topic guidelines
16:35:17 <etoews> the #link http://ghostcloud.net/openstack_gerrit_dashboards/dashboard_api-wg.html is borked :(
16:35:44 <etoews> but #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z is pretty manageable.
16:36:01 * cdent nods
16:36:17 <elmiko> hmm, can we put server-side tracebacks up for freeze?
16:36:32 <etoews> yes
16:36:52 <elmiko> doesn't look like anything else is ready
16:36:54 <cdent> yes
16:37:02 <etoews> ameade: rosmaita: anything you want to discuss here?
16:37:08 <elmiko> #action elmiko freeze the server-side traceback guideline
16:37:33 <cdent> this guideline probably requires a fair bit of thought about the precedents it will set: https://review.openstack.org/#/c/273158/
16:37:40 <rosmaita> etoews: yeah, i don't want to hold up actual work other people are trying to do while i slowly work on the versions thing
16:38:36 <etoews> ah. i get where you're coming from. i'm pretty much resigned to the fact that most guidelines take a long time to happen.
16:39:48 <etoews> if people need something like versions discovery right away, then they'll just have to do the best they can until the guideline settles.
16:40:04 <rosmaita> ok
16:40:33 <rosmaita> etoews: anyway, your action item to get some eyes on it worked
16:40:39 <etoews> it's not like we're the first group to try to bring guidelines/standards to something while it is in development.
16:40:42 <etoews> nice
16:40:45 <elmiko> i've been watching that one too, i'd like to improve our version page in sahara
16:40:47 <rosmaita> so i will revise in line with jay's comments
16:40:56 <rosmaita> not sure that helps ameade though
16:41:03 <etoews> yep. some good stuff in there.
16:41:14 <elmiko> i do have a question about updating the version response and server versions
16:41:21 <etoews> we need to get a feel for what projects are already using jsonhome
16:41:45 <etoews> and document that in #link https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Version_Responses
16:42:03 <etoews> any volunteers for that ^?
16:42:05 <elmiko> i can try and add a few more projects to that page
16:42:13 <elmiko> i'll start with zaqar ;)
16:42:18 <etoews> thx elmiko
16:42:47 <elmiko> something to consider for the guideline, and this is kinda meta, but how does changing the version page affect the semver?
16:43:10 <elmiko> like, if you change your root home page, would that necessarily mean bumping the major version since you will break the api contract?
16:43:21 <etoews> rosmaita: does ameade need to implement something very soon?
16:43:57 <rosmaita> he sent soemthing the the ML today
16:44:04 * rosmaita looking for link
16:44:22 <ameade> paying attn now one sec
16:44:22 <scottda> hi
16:44:29 <etoews> elmiko: thinking...
16:44:44 <scottda> ameade: is helping Cinder to determine the string we used for api-microversion header
16:44:44 <elmiko> yea, it's a toughie
16:45:10 <rosmaita> #link http://lists.openstack.org/pipermail/openstack-dev/2016-January/085229.html
16:45:27 <scottda> We *think* Api-microversions will land soon in Cinder
16:45:33 <ameade> rosmaita: you beat me!
16:45:47 <scottda> and currently use "X-OpenStack-Cinder-API-microversions"
16:46:02 <scottda> consistent with Nova, Manila, etc.
16:46:09 <etoews> elmiko: you could do something rude and just 301 redirect
16:46:17 <cdent> ameade: in discussions today with nova people, there's a vague plan for nova to start supporting both X-OpenStack-Nova-API-Version and OpenStack-Compute-Version
16:46:21 <cdent> (or something close to that)
16:46:23 <elmiko> so, given the current conversations on ML, that should probably be "X-OpenStack-Block-Storage-API-microversions"
16:46:32 <cdent> no X
16:46:39 <elmiko> er yea, i knew that felt wrong
16:46:45 <cdent> sorry that was supposed to be a question "no X?"
16:46:50 <scottda> OK, and no Cinder?
16:46:55 <scottda> use Block?
16:46:56 <elmiko> yea, drop the cinder
16:47:03 <cdent> is "API" redundant?
16:47:07 <elmiko> our preference is service type when possible
16:47:24 <elmiko> cdent: hmm, good question
16:47:52 <etoews> scottda: ameade: see http://specs.openstack.org/openstack/api-wg/guidelines/headers.html
16:48:07 <elmiko> i think api is redundant, but it is also explicit, so i'm torn
16:48:43 <cdent> but as far as we were concerned in the earlier conversation the service and the API are congruent
16:48:51 <ameade> i think we should nail down what cinder shoud do and add some sort of header aliases in nova and manila
16:49:00 <elmiko> ameade: +1
16:49:04 <cdent> ameade: yeah the aliases are coming in nova
16:49:08 <cdent> (no timetable)
16:49:15 <ameade> kk cool
16:49:24 <elmiko> imo, cinder should use "Block-Storage" and nova/manilla should create service type aliases
16:49:30 <scottda> OK, Cinder is imminent, so we want to get it right
16:49:33 <cdent> the meandering right now is trying to determine the exact correct form of the proper header
16:50:04 <scottda> OpenStack-Block-Storage-API-microversion ?
16:50:20 <elmiko> cdent: i think we could drop the API, since when are you going to request anything else *but* the API microversion
16:50:32 <etoews> ya. drop the API.
16:50:45 <scottda> That's ok with me.
16:50:57 <cdent> me too
16:50:58 <scottda> OpenStack-Block-Storage-microversion
16:51:04 <ameade> i'm cool with that
16:51:18 <cdent> ameade: you happy to respond to your own mail message (to report on what we've just decided)?
16:51:20 <rosmaita> is the type 'block-storage' or 'volume' ?
16:51:32 <cdent> rosmaita: I was going to ask that too
16:51:37 <cdent> I don't know the server catalog identifiers well
16:51:53 <rosmaita> i thought it was 'volume'
16:51:56 <elmiko> according to governance, it's "Block Storage service"
16:52:03 <elmiko> http://governance.openstack.org/reference/projects/cinder.html
16:52:10 <scottda> I *think* service catelog uses block storage
16:52:11 <rosmaita> yeah, but what is 'type' in the service catalog?
16:52:12 <elmiko> maybe that's different than the service catalog though
16:52:33 <etoews> ugh. https://review.openstack.org/#/c/243429/3/guidelines/microversion_specification.rst currently recommends putting API in there.
16:52:34 <cdent> devstack appears to use "volume"
16:52:57 <rosmaita> i think we need to be consistent with the service catalog
16:52:58 <elmiko> etoews: hmm
16:53:02 <ameade> docs uses 'volume'
16:53:05 <ameade> rosmaita: +1
16:53:15 <etoews> don't go by devstack
16:53:27 <elmiko> agreed about consistency with service catalog, but isn't the service catalog supposed to agree with governance?
16:53:55 <etoews> agentleweb: do you know ^ w.r.t. your work on the service catalog?
16:54:01 <cdent> etoews: the discussion amongst the service catalog next-gen people is that most people use devstack as the precent setter. Not that that is _good_.
16:54:07 <elmiko> etoews: do we need to recommend dropping "API" on that review?
16:54:14 <etoews> elmiko:
16:54:16 <etoews> elmiko: yes
16:54:20 <elmiko> k
16:55:38 * cdent would like to learn to type
16:56:37 <etoews> just commented on removing API from the header
16:57:12 <ameade> starting my vm to see whats in the catalog lol
16:57:13 <elmiko> ack, thanks
16:57:34 <agentleweb> etoews: oh sorry, I'm on a web irc client and didn't see
16:57:40 <elmiko> my devstack has "volumev2"
16:57:44 <agentleweb> I went to the keystone midcycle yesterday and talked about the service catalog
16:57:55 <etoews> ameade: why see one service catalog when you can see ALL THE SERVICE CATALOGS! https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog
16:57:56 <scottda> So should I be using the service catelog type, i.e. "volume" or name "Block Storage"
16:57:58 <elmiko> i don't think that makes sense for the header though
16:58:07 <cdent> elmiko: do you have both volume and volumev2?
16:58:20 <elmiko> oh, yes. i do
16:58:39 <agentleweb> "Known types such as service_type can be documented in projects.yaml in the openstack/governance git repository." from http://specs.openstack.org/openstack/openstack-specs/specs/service-catalog.html
16:58:51 <agentleweb> so volume2 needs to be stopped
16:58:56 <elmiko> scottda: imo, we should attempt to standardize on the official service type, but i defer to agentleweb on service catalog stuff
16:59:04 <etoews> we'll have to move this to #openstack-sdks in a minute.
16:59:07 <ameade> agentleweb: that's weird +1
16:59:37 <agentleweb> cdent: and my ask of the keystone team is a json schema and tempest test for service catalog entries so devstack's service catalog is a shining example of correctness
17:00:00 <etoews> schemas and tests???!?!!! madness.
17:00:08 <scottda> OK, so I don't quite know what the answer is for my issue
17:00:16 <agentleweb> etoews: I want the Mr. Burns icon
17:00:16 <etoews> thanks all! let's move to #openstack-sdks
17:00:19 <agentleweb> sure
17:00:21 <etoews> #endmeeting