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