00:00:44 #startmeeting api wg 00:00:44 Meeting started Thu Mar 5 00:00:44 2015 UTC and is due to finish in 60 minutes. The chair is sigmavirus24. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:00:45 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:00:48 The meeting name has been set to 'api_wg' 00:00:57 o/ 00:00:59 o/ 00:01:03 o/ 00:01:08 etoews: asked me to run the meeting again 00:01:10 o/ i'll be here for only 10-15 min 00:01:13 I apologize in advance =P 00:01:17 hi 00:01:17 lol 00:01:25 #topic agenda 00:01:32 #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda 00:01:48 #topic versioning 00:01:51 etoews: ? 00:02:07 sorry for being so vague with that one 00:03:03 now that we have the mission statement done. it seems the next most asked question is "how to i take my api from current state to following your guidelines?" 00:03:21 oh I was supposed to write a strawman for that 00:03:25 it would be helpful to have a reasoned response 00:03:46 but i'm not proposing we solve api versioning in the next 10 min 00:03:54 and.. go! 00:04:15 :D 00:04:18 yep, we should make sure that ironic and nova versioning are compatible from the rest api point of view (which I think they are even if the implementation may be a bit different in places) 00:04:31 i think starting with some sort of high-level workflow type thingie would be useful 00:04:53 even if it's just bullet points for now 00:05:18 +1 00:05:36 sigmavirus24: what form was that strawman to take? 00:05:54 A guideline proposing a strategy for migrating to our guidelines 00:06:07 sgtm 00:06:08 nice, kinda meta too ;) 00:06:09 I think we had discussed it last year 00:06:23 meta-guideline 00:06:28 i remember the email thread you kicked off 00:06:41 Should we have guidelines to help write meta-guidelines? /kidding 00:06:42 etoews: yes 00:06:44 *feels bad for not responding to that thread* 00:06:50 sigmavirus24: LOL 00:06:52 etoews: people did, just not a lot 00:07:12 sigmavirus24: remember to include the CPLs on the review 00:07:13 okay 00:07:17 etoews: will do 00:07:27 #action sigmavirus24 to write versioning/migration guideline 00:07:42 #topic #openstack-api channel 00:08:05 So after the last meeting a few of us discussed the idea of #openstack-api and after a quick check with etoews today I went ahead and made it figuring it was better to ask for forgiveness 00:08:19 \o/ 00:08:21 I sent a message to the mailing list but in case you missed it here area the relevant Changes 00:08:22 #link https://review.openstack.org/#/c/161330/ 00:08:27 #link https://review.openstack.org/#/c/161337/ 00:08:42 One adds logging the other adds notifications from openstack/api-wg 00:08:50 Please weigh in either on the ML or those changes or both 00:09:13 If anyone wants to discuss it quickly we can, but I'd like to keep that short 00:09:18 sounds good to me 00:09:32 no complaints here 00:09:53 #topic merge the mission? 00:09:59 #link https://review.openstack.org/#/c/155911/ 00:10:03 etoews: ? 00:10:08 +1 00:10:14 +1 from me 00:10:40 i think it passes the api wg merge rules at this point. 00:10:47 yea that has more than enough votes and no negative 00:10:51 cyeoh: care to merge the mission statement? 00:11:02 sure! 00:11:37 thanks! i know that was a somewhat painful exercise but i appreciate everyone's patience 00:11:46 You did good etoews 00:11:55 hopefully it will make for a smoother path 00:12:06 yea, etoews++ 00:12:35 #action update the wiki page with the mission statement 00:13:06 #topic previous meeting action items 00:13:16 #link http://eavesdrop.openstack.org/meetings/api_wg/2015/api_wg.2015-02-26-16.00.html 00:13:30 (There were none from 19 Feb 2015 so I dropped that link) 00:13:43 kaufer doesn't seem to be around 00:13:55 alright. i need to duck out now. ciao. 00:14:00 later 00:14:01 bye etoews 00:14:10 miguelgrinberg: I don't recall seeing messages from you on the ML 00:14:13 hmm, completely forgot about mine, will do this week 00:14:27 #action kaufer to gather more API-WG consensus on https://review.openstack.org/#/c/147684/5 before bringing it to the ML 00:14:37 #action miguelgrinberg to get ML feedback on https://review.openstack.org/#/c/141229/ 00:14:45 #action miguelgrinberg to bring tagging guideline to the ML https://review.openstack.org/#/c/155620/ 00:14:54 e0ne and yuriy who aren't even members got their item done ; 00:14:55 *;) 00:15:03 nice 00:15:26 I think that'll come up in the next section 00:15:35 I'll ping kaufer when I see him about his action item tomorrow 00:15:46 #topic guidelines 00:15:53 #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z 00:16:04 #link https://review.openstack.org/159892 00:16:15 ^ That is Yuriy's guideline 00:16:32 I personally think it needs some help from one of our more experienced guideline authors 00:16:46 #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z 00:16:54 (In case meetbot doesn't strip leading whitespace) 00:17:33 Further I think the guideline should recommend a format for the datetime to be serialized to when returned via the api 00:17:51 agreed 00:17:52 do you all like UTC vs something like the ISO date format which can support any TZ? 00:17:55 something like calling datetime_instance.iso8601() would be preferable 00:18:17 miguelgrinberg: so this is particularly talking about timezone where as the format itself is not defined there 00:18:25 i like the use of UTC, but having a strong opinion on formatting is nice as well 00:18:28 That said, I think it's best if all datetimes are returned as the same timezone 00:18:44 well, if everybody speaks ISO then it does not matter 00:18:48 Right 00:18:49 true 00:19:04 can javascript parse ISO dates? I think it can, but not sure 00:19:05 But still, people using plain old datetime will have trouble 00:19:06 I think there was some cleanup work around this in Nova last year, but I can't remember what was settled on. 00:19:08 moment.js surely can 00:19:15 miguelgrinberg: google's closure tools can 00:19:31 cyeoh: could you research that and comment on the spec? 00:19:44 yep, will do 00:20:01 #action cyeoh to look into how nova handled datetimes and comment on Yuriy's guideline 00:21:19 Anyone else have guidelines in progress they want to call out? 00:21:23 miguelgrinberg: elmiko cyeoh ? 00:21:50 nothing as of yet 00:21:59 nothing from me 00:22:01 should we merge https://review.openstack.org/#/c/131320/? 00:22:10 it's been out there for ages 00:22:42 It doesn't have any -1s 00:22:46 lgtm 00:23:15 I'd like to get to the point where we can do it, but I know for Nova it will be a while 00:23:38 I managed to sneak an implementation of this into Heat :) 00:23:40 because of the requirement to return a list of valid methods 00:23:56 miguelgrinberg: I recall :D 00:24:19 cyeoh: yeah, I expect that'll be v4 of nova (since I'm guessing y'all won't be reusing v3 ;)) 00:24:37 v3 name is cursed ;-) 00:24:53 cyeoh: you say because it is hard to compute the methods associated with a URL? 00:24:54 What happens if you look in the mirror and say "v3" 3 times? 00:25:02 lol 00:25:50 miguelgrinberg: yes and I suspect it got even a bit harder with microversions because the response has to reflect the version of the api requested as well 00:26:52 cyeoh: okay 00:27:20 sigmavirus24: mirrors have been known to shatter :-) 00:28:12 I'd really like more people to read https://review.openstack.org/#/c/141229/ and discuss it there, so don't feel pressed to read it now and respond 00:28:14 #link I'd really like more people to read https://review.openstack.org/#/c/141229/ 00:28:19 ugh 00:29:01 I was thinking that to support swift's URLs I can stick the /metadata as a prefix, not a suffix. What do you guys think? 00:29:23 so it will be recommended as a suffix, but allowed as a prefix as well 00:29:47 suffix as an option, or just for swift? 00:29:50 er prefix 00:30:10 it would be a prefix when the URL has variable components with slashes, so file system type URLs 00:30:18 right, makes sense 00:30:42 I'll add that and advertise on the ML 00:30:43 We should probably ask swift to write a guideline on dealing with URLs that have variable components like filenames 00:31:01 they have that, they use HTTP headers 00:31:02 #action miguelgrinberg to update the metadata guideline and advertise it on the ML 00:31:37 miguelgrinberg: it just seems like they already feel alienated from the group. so this would be a way of having them feel like their input is wanted 00:31:55 I'm pretty sure my RFC citing was antagonistic, but hindsight is 20/20 00:32:27 and aws does the same thing, btw 00:32:33 a good move towards inclusion 00:33:12 We have plenty of time left, should we continue with guidelines or move onto APIImpact? 00:33:34 * sigmavirus24 realizes there's an analogy between heat and himself orchestrating this meeting 00:34:47 :crickets: 00:35:30 we've almost gone through all the guidelines, maybe just finish them out? 00:35:49 WFm 00:36:05 https://review.openstack.org/147684 seems to be overall fairly positively received 00:36:24 #link https://review.openstack.org/147684 00:36:35 very non-controversial 00:36:43 it's also been around for a while 00:38:07 yea the only issue I had a round it was defining true/false 00:38:12 but that can wait till later 00:38:13 aside from the whole true/false issue, is it ready for merging? 00:39:14 +1 00:39:33 +1 00:39:41 * sigmavirus24 thinks true/false will be far more controversial 00:39:49 could be 00:39:54 i'm +1 for merge too 00:40:09 +1 00:40:46 ok we have enough votes so I'll merge it 00:40:46 a consensus of 4 00:40:48 ;) 00:41:05 #link https://review.openstack.org/155620 00:41:13 That's miguelgrinberg's tagging guideline 00:41:32 (And the last two are from Sam Harwell when the group started way back when) 00:42:00 i haven't checked this one out yet 00:46:03 instance tags is just going through nova queue at the moment. So I'd want to double check consistency 00:46:44 cyeoh: it's close, but not identical 00:47:35 cyeoh: one thing nova does not have is negative filtering of tags 00:47:49 ok. also I think we'll need to make some statement around naming beyond what we have - eg length, unicode, etc to avoid issues we've had in the past where we break because some unicode characters aren't supported by mysql 00:47:51 looks pretty solid on a first readthrough, i can already see that the swift folks probably wouldn't like the .../tags endpoint 00:48:11 elmiko: same as with /metadata, yeah 00:48:45 i wonder if between this and the metadata there is room to expand on the whole prefix/suffix endpoint thing and make it a more general guideline? 00:48:56 elmiko: right and their opinions should be heard, but they seem to have checked out already 00:49:09 elmiko: I was thinking the same thing 00:49:12 sigmavirus24: total agreement about hearing their opinions 00:49:34 maybe a guideline on how to work with dynamic/variable-length resource URLs 00:49:43 right 00:49:58 then we could avoid having that language in the metdata and tag guidelines 00:50:04 can we ask them to kick that off? 00:50:14 if they're amenable to the idea, sure 00:50:17 they are the experts 00:50:28 we might have to build some bridges back into the swift community though :/ 00:51:03 or at the least mend them 00:51:39 yep 00:51:49 no permanent damage has been done, we haven't merged anything they dislike 00:51:55 cool 00:52:00 yet 00:52:04 hehe ;) 00:52:07 :) 00:52:16 Oh shoot 00:52:19 8 minutes left 00:52:22 APIImpact? 00:52:32 should we discuss versions? 00:52:40 or do we leave that for another day? 00:52:53 I mean versions for services behind proxies 00:53:21 can we cover it in the remaining time? 00:53:40 not sure, have you guys seen sigmavirus24's email on the ML? 00:53:45 miguelgrinberg: heh 00:53:56 * notmyname will be happy to talk about swift things 00:54:06 I haven't commented because I haven't seen things 00:54:12 Hi notmyname ! 00:54:19 miguelgrinberg: not sure, what was it tagged under? 00:54:36 elmiko: lots of tags including [glance] and [all] 00:54:42 It's less ofa question for us though I think 00:54:44 elmiko: [api] I think, it's about reporting base URLs when the service is behind a proxy 00:54:51 * sigmavirus24 is more interested in talking to notmyname 00:54:53 i don't think i've read it 00:55:02 sigmavirus24: yea, that might be more productive at this point 00:55:07 yes 00:55:41 sigmavirus24: I just got back online for a little while, and it looks like your meeting time is almost up. what irc channel do the api wg people lurk in? 00:55:50 #openstack-api 00:55:52 We just made it today 00:57:13 So tl;dr on miguelgrinberg's topic: if a service is behind a proxy it reports the wrong version urls 00:58:04 it should report the proxy's root URL, not its own 00:58:51 Correct 00:59:11 There's an RFC that was published recently defining de jure headers to be sent by proxies 00:59:22 But the de facto ones are the ones we'll likely see and want to standardize around for now 00:59:30 (While also supporting proxies that are RFC compliant) 00:59:39 (Also hattip to miguelgrinberg for finding that RFC) 00:59:49 I have an awesome teacher :) 00:59:49 tl;dr, Glance found it first and I'm going to write a better fix 00:59:55 5 s 01:00:00 #endmeeting