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