16:00:04 <etoews> #startmeeting api wg
16:00:07 <openstack> Meeting started Thu Jul  7 16:00:04 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:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:10 <openstack> The meeting name has been set to 'api_wg'
16:00:21 <cdent> o/
16:00:25 <rosmaita> o/
16:00:29 <elmiko> heyo/
16:00:31 <etoews> #chair elmiko cdent
16:00:32 <openstack> Current chairs: cdent elmiko etoews
16:00:39 <etoews> good day
16:01:51 <elmiko> definitely, although i think it's gonna rain here :/
16:01:51 <etoews> #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
16:02:07 <etoews> #topic proposal for a new Glance schema for v2/schemas/member response
16:02:22 <etoews> #link https://bugs.launchpad.net/glance/+bug/1585917/comments/3
16:02:22 <openstack> Launchpad bug 1585917 in Glance "member-create will raise 500 error if member-id is greater than 255 characters" [Undecided,Confirmed] - Assigned to Abhishek Kekane (abhishek-kekane)
16:02:29 <etoews> #link http://developer.openstack.org/api-ref-image-v2.html#showImageMemberSchema
16:02:37 <etoews> take it away rosmaita
16:02:39 <rosmaita> so i don't type a bunch of json in here, take a look at this: https://etherpad.openstack.org/p/member-schema-situation
16:03:37 <rosmaita> problem is that the current schema describes the response, but not the request
16:03:40 <elmiko> ooph
16:04:02 <elmiko> is there a non-historical reason why so much information is passed through the path for creation?
16:04:54 <rosmaita> not sure, but the idea is a member is a resource on another resource
16:05:28 <elmiko> ah, ok. so the path info actually helps to locate the resource, is that accurate?
16:05:32 <rosmaita> it seemed like a good idea at the time
16:05:35 <rosmaita> yes
16:06:08 <elmiko> ok, thanks. yeah, i'm not casting any opinion about the usage, just trying to understand =)
16:06:30 <rosmaita> so the sketch on comment/3 on that bug linked above is an attempt to be backward compatable as far as request/response goes
16:06:51 <rosmaita> because another proposal is to accept *either* member: or member_id: on the request
16:07:01 <rosmaita> which we'd prefer to avoid
16:07:31 <rosmaita> elmiko: :)
16:07:40 <elmiko> is that bug based on the member_id being passed in the url, which then becomes too long?
16:08:15 <rosmaita> no, it's that in the member-detail response, it's identified as "member_id"
16:08:25 <rosmaita> but in the member-create request, it's identified as "member"
16:08:34 <elmiko> ahh, got it
16:08:36 <elmiko> thanks
16:08:39 <rosmaita> np
16:09:07 <rosmaita> i just wanted to float this idea and see what y'all think of that schema
16:09:15 <elmiko> seems like making the body accept schema a little looser is one way to solve this
16:10:20 <elmiko> would the team ever plan to deprecate one or the other?
16:10:27 <cdent> what would the negatives of accepting both be?
16:10:46 <rosmaita> just general ugliness
16:10:57 <rosmaita> not sure about deprecation
16:10:57 * cdent looks around
16:10:58 <cdent> :D
16:11:36 <rosmaita> the new schema would allow us to codify the current practice, wouldn't need to deprecate anything
16:12:21 <cdent> I think that's better than leaving it as it is
16:12:25 <elmiko> the schema looks fine to me, i don't have a strong feeling about the inclusion of both names. it seems to be solving a difficult issue, i'd be ok with it.
16:13:05 <rosmaita> i'm curious what you think of it as an approach where you have asymmetric request/response bodies
16:13:21 <rosmaita> or is it a bad practice to have asymmetric request/response bodies in the first place
16:13:34 <elmiko> well, my preference would be to quash the asymmetry, but that may not be an option here
16:13:39 <cdent> rosmaita: that's a religious question
16:13:45 <elmiko> exactly.. ;)
16:13:58 <cdent> orthodoxy would say it is bad
16:14:03 <rosmaita> cdent: i am a lapsed restafarian
16:14:11 <elmiko> lol
16:14:26 <cdent> most people are (I am)
16:15:09 <elmiko> given the state of things, i'm not sure there is a better solution. i mean, changing the values leads to the path of deprecation, which leads to madness.... \o/
16:15:51 <elmiko> or, alternatively, creating some new endpoints for members. which sounds undesirable from my understanding
16:16:28 <rosmaita> elmiko: definitely undesirable from my perspective!
16:17:15 <rosmaita> quick technical question: i have everything marked readOnly in the response, even status
16:17:33 <rosmaita> which is *not* readonly in #/definitions/image-member-update-request
16:17:43 <rosmaita> not sure that's correct
16:18:08 <rosmaita> i was thinking, you cannot submit the #/definitions/image-member-detail-response as a request body
16:18:13 <elmiko> if it's the response, i wouldn't think it should matter
16:18:25 <rosmaita> ok, that's basically my question
16:19:32 <rosmaita> ok, this has been helpful ... don't know what way glance will go on this, but i wanted to get some early feedback on this option
16:19:37 <rosmaita> thank you!
16:19:38 * cdent needs to level up on json schema
16:20:01 <cdent> thank you rosmaita, it's nice having people come round for a visit
16:20:06 <elmiko> yeah, i'd have to check my jsonschema notes. that stuff is way too dense for me to remember it all ;P
16:20:17 <etoews> i'm heavily distracted here. please carry on without me.
16:20:19 <elmiko> cdent++
16:22:04 <elmiko> #topic guidelines
16:22:20 <elmiko> #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
16:22:35 <cdent> I need to decide what to do about the details boolean example in the url guideline
16:22:38 <elmiko> that list has shrunk considerably
16:22:57 * elmiko looks
16:24:11 <elmiko> cdent: what does json permit for boolean values?
16:24:32 <cdent> true or false
16:24:39 <cdent> but that's not really the issue
16:24:53 <cdent> we don't want to cloud the example there by having something fuzzy
16:25:03 <elmiko> right, i was more curious about the possibility of relying on the json standard for the language used in the uri
16:25:06 <cdent> so I need a different way to say the right thing without needing an ambiguous answer
16:25:24 <cdent> I suppose that might be oka
16:26:05 <elmiko> i totally get the ambiguity issue, but i'm not sure i like the idea of using something like `?details` `?nodetails`
16:26:27 <elmiko> i mean, at least that is clearer i suppose
16:26:58 <elmiko> i dunno, maybe that is the best idea
16:27:34 <cdent> It doesn't need to be a stopper, but it seems people will read anything put there as normative (I could warn that it is not?)
16:28:13 <elmiko> yea, agreed
16:28:30 <cdent> ✔
16:29:19 <elmiko> i guess the question is, do we advise using some sort of boolean values, or as Dolph suggests, do we recommend a well defined default with a param for switching it
16:30:08 <elmiko> gotta say, that his suggestion does seem to reduce ambiguitiy at the cost of no clear standard for boolean options
16:30:23 <elmiko> i mean, the parameter key will be whatever you choose basically
16:30:57 * cdent nods
16:32:29 <cdent> I'll meditate upon these things and make a new version. It doesn't feel like we're going to have a clear insight today.
16:33:19 <elmiko> ++
16:34:02 <cdent> my ride (my sister) is departing soon, so I may need to bail out soon
16:34:13 <elmiko> ack
16:34:19 <elmiko> should we merge https://review.openstack.org/#/c/330687 ?
16:34:36 <cdent> yes
16:35:03 <elmiko> ok, done
16:35:11 <elmiko> got my review for this cycle in ;P
16:36:06 <elmiko> seems like we could merge this too https://review.openstack.org/#/c/330876
16:36:55 <cdent> yup, done
16:36:59 <elmiko> \o/
16:38:00 <elmiko> should we work up a new version of the newsletter quickly?
16:38:54 <cdent> yeah, best you be the poster this time since I might disapper
16:39:24 <elmiko> ok, should be pretty easy. looks like not much new happening. although i'll note those 2 reviews we merged
16:41:22 <cdent> #link https://etherpad.openstack.org/p/api-wg-newsletter
16:41:27 <cdent> just for reference
16:41:37 <elmiko> is that preferred over the wiki copy?
16:42:27 <cdent> we've tended to edit that one for each new version
16:42:34 <cdent> since there's usually much of the same stuff
16:42:34 <elmiko> ok, cool
16:42:48 <cdent> edit each section, add an intro at the top, done
16:43:01 <cdent> I've removed the intro, but can't think of what to put there this time
16:43:03 <elmiko> should i add that stuff in the etherpad then?
16:43:11 <elmiko> i'll make something up ;)
16:44:34 <cdent> ✔
16:46:45 <cdent> looks good
16:46:57 <elmiko> ok, added a little intro and removed old links. otherwise, i think you did the heavy lifting of adding the new links =)
16:47:02 <elmiko> cool, i'll ship it!
16:47:35 <elmiko> should we close up shop then?
16:47:45 <cdent> yeah, reckon so
16:47:56 <elmiko> k, take care =)
16:47:59 <elmiko> o/
16:48:03 <elmiko> #endmeeting