16:00:21 <elmiko> #startmeeting api wg
16:00:22 <openstack> Meeting started Thu Jul 30 16:00:21 2015 UTC and is due to finish in 60 minutes.  The chair is elmiko. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:26 <openstack> The meeting name has been set to 'api_wg'
16:00:35 <elmiko> hey ppls
16:00:40 <cdent> hola
16:00:45 <miguelgrinberg> good morning
16:00:55 <stevelle> hellos
16:01:03 <elmiko> #topic agenda
16:01:15 <elmiko> #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
16:01:55 <Nikolay_St> hello
16:02:37 <elmiko> so, no actions from last meeting, or the one before
16:02:42 <annegentle> o/
16:03:04 <elmiko> #topic guidelines
16:03:21 <elmiko> #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
16:03:42 <elmiko> we had 3 guidelines that will be merging today
16:03:52 <elmiko> 1 already did, but the other 2 aren't for some reason
16:04:00 <sigmavirus24> o/
16:04:10 <elmiko> we did have one guideline that will need further review
16:04:18 <elmiko> Add new guideline for HTTP Headers #link https://review.openstack.org/#/c/186526/
16:04:20 <sigmavirus24> elmiko: zuul is about 7.5 hours behind
16:04:31 <elmiko> sigmavirus24: ok, i figured it was something like that
16:04:40 <sigmavirus24> they notified all channels that they wanted them to not approve things for a while
16:04:48 <elmiko> oops =(
16:04:50 <sigmavirus24> or at least all channels with 'openstackstatus' in it
16:05:27 <elmiko> so, the one guideline that needs further review had some nice comments that came up in the cross project meeting
16:05:59 <elmiko> i think ryan is on pto and this was his review, so i'm not sure if we should discuss it or not. thoughts?
16:08:06 <elmiko> the other guidance topic that has come up is the PATCH stuff
16:08:41 <elmiko> we currently have a small section on how to use PATCH but i think we might do well by helping to define a little more about rfc6902 and partial resource updating
16:09:09 <elmiko> i'm going to post something to the ML about this, but i think we should add a small note about being consistent within an application
16:09:35 <elmiko> i don't think we can say "use 6902" or "use partial resource", but the main guidance is to keep consistent within an app
16:09:47 <elmiko> anyone have thoughts on this one?
16:10:32 <cdent> I think "keep consistent" is the only sane choice
16:11:21 <elmiko> a good corner case that was brought up is the idea that partial resource update doesn't allow nulling a value
16:11:40 <elmiko> i wonder if we can point out some of these cases
16:12:28 <miguelgrinberg> elmiko: I'm not big on partial resource update, but I suppose you can set a value to a JSON null if you have to
16:13:22 <elmiko> miguelgrinberg: do you think it's worth trying to advise projects to use 6902 when possible?
16:13:42 <elmiko> or prefer 6902 over partial resource update
16:14:14 <miguelgrinberg> I would advice to try to not use either one, but if you have to use one, JSON patch seems more well rounded
16:14:22 <elmiko> hehe
16:14:25 <elmiko> fair
16:14:31 <miguelgrinberg> A third approach is the sub-resource style
16:14:41 <miguelgrinberg> which we are employing with tags and metadata
16:14:47 * cdent is not a fan of JSON Patch
16:14:56 <cdent> but wouldn't want to prevent people from using it
16:14:58 <miguelgrinberg> cdent: don't get me wrong, I don't like it either
16:15:16 <miguelgrinberg> my main beef is that the body is not a resource representation but a set of ops
16:15:16 <elmiko> miguelgrinberg: can describe sub-resource a little more, i'm not totally familiar with that style
16:15:41 <miguelgrinberg> so lets say you hava a resouce with fields foo, bar and baz at http://example/resource
16:16:06 <miguelgrinberg> then you can access the fields as http://example/resource/foo, http://example/resource/bar and http://example/resource/baz
16:16:15 <elmiko> ah, interesting
16:16:17 <miguelgrinberg> to set one of those to null send a DELETE
16:16:28 <miguelgrinberg> if one of them is a collection, you can use the full REST semantics
16:16:44 <miguelgrinberg> this is what I proposed in tags and metadata
16:16:48 <miguelgrinberg> you guys liked it :)
16:16:58 <elmiko> might be worth presenting this as an option in the PATCH guidelines
16:17:09 <elmiko> yea, i remember now =)
16:17:38 <miguelgrinberg> the only drawback vs. json patch or partial resource is that you can only do one field at a time
16:17:39 <stevelle> that seems like the right kind of guideline, even if we don't feel strongly in favor, to outline so that folks don't invent something else
16:18:16 <elmiko> ok, i'll send out an email about this and hopefully we can start to build a consensus about a guideline update
16:18:44 <elmiko> #action elmiko send message to ML about PATCH guideline update and discussion
16:19:35 <elmiko> does anyone have suggestions for guidelines that we should freeze next?
16:20:23 <elmiko> i think we have a few that might be close
16:20:36 <elmiko> #link https://review.openstack.org/198547
16:20:44 <elmiko> #link https://review.openstack.org/197871
16:20:55 <elmiko> #link https://review.openstack.org/199597
16:23:43 <elmiko> also, i think we have a few that should merge but are being held up by #link https://review.openstack.org/#/c/183456
16:23:55 <elmiko> sdague: maybe you could take another pass at that ^^
16:24:31 <sdague> elmiko: I can try, I feel like I've said almost everything I can about that one
16:25:07 <elmiko> sdague: ok, not sure where to go on that one. the other 2 dependent changes are ready to go... =(
16:25:38 <sdague> I don't think we're going to get 100% concensus on that one, because a lot of people got used to doing it
16:25:50 <sdague> so basically, the question is what's the role of the wg
16:26:17 <sdague> only specify 100% concensus items, or at times say "no, seriously, we're doing this wrong, and we have to do the right thing"
16:26:21 <elmiko> yea... this is a touchy subject for some reason
16:26:42 <miguelgrinberg> elmiko: rework the two dependencies to stand on their own?
16:26:52 <stevelle> we have a standard for how much dissent we can have and pass something, not finding it quickly though
16:26:53 <sdague> I can restack the others
16:26:58 <elmiko> miguelgrinberg: that might be the best path forward
16:27:06 <elmiko> thanks sdague
16:27:08 <miguelgrinberg> happy to do mine
16:27:14 <sdague> but I'll be honest, the 501 issue for me is a unit test of our process
16:27:20 <sdague> because it is important to address items like this
16:27:42 <elmiko> agreed, maybe we should wait a week for etoews to return
16:27:47 <elmiko> i think he should be involved with this
16:27:50 <sdague> sure
16:28:15 <elmiko> #info revisist https://review.openstack.org/#/c/183456 when etoews returns
16:28:20 <elmiko> #undo
16:28:21 <openstack> Removing item from minutes: <ircmeeting.items.Info object at 0xa130c10>
16:28:29 <elmiko> #info revisit https://review.openstack.org/#/c/183456 when etoews returns
16:28:46 <elmiko> ok, moving on
16:28:54 <elmiko> #topic guideline pipeline
16:29:03 <elmiko> #link http://ghostcloud.net/openstack_gerrit_dashboards/dashboard_api-wg.html
16:29:23 <elmiko> etoews started working on this dashboard link, i added a little patch and have been looking to improve it more
16:29:56 <elmiko> i'd love to hear ideas if anyone has them, maybe on ML or in reviews
16:31:26 <elmiko> that brings us to the next point
16:31:34 <elmiko> #topic merge guidelines
16:31:48 <elmiko> so, the -2 thing doesn't really work for freezing imo
16:31:57 <elmiko> and i'm not sure -A would be any better
16:32:18 <elmiko> anyone know if we can use tags in comments to trigger gerrit search stuff?
16:32:32 <sigmavirus24> elmiko: don't know of a way
16:33:15 <sigmavirus24> elmiko: Are -2's not working because, e.g., etoews goes on vacation and then you can't approve it till he gets back?
16:33:16 <elmiko> the dashboard is currently keying of a -2 for frozen stuff, but the issue is that it can't be overridden
16:33:22 <elmiko> sigmavirus24: yea
16:33:38 <elmiko> a -A could be overridden, but then folks can't use it to mark WIP on a spec
16:33:43 <elmiko> er guideline
16:34:14 <elmiko> the infra folks suggested this is more a social contract kinda thing, but then we can't have the dashboard show the reviews in freeze
16:34:37 <elmiko> i'm kinda guessing this is a "talk with etoews" type of subject as well ;)
16:34:47 <cdent> if it possible/workable to change the topic?
16:34:58 <cdent> s/if/is/
16:35:05 <elmiko> hmm, interesting idea
16:35:15 <sigmavirus24> cdent: that's something we could do
16:35:24 <sigmavirus24> but that doesn't prevent accidental merges which was etoew's hope
16:35:30 <elmiko> ah
16:35:31 <sigmavirus24> *etoews'
16:35:39 <sigmavirus24> So my thing is that it is a social contract thing
16:36:02 <sigmavirus24> If one of you is blocking it and will be unavailable, swap the blocking vote
16:36:42 <cdent> a) how big is the risk of accidental merge happening b) how big is the cost of cleaning up after an accidental merge (or even having it happen)
16:37:01 <cdent> it seems to me that there are solutions abounding looking for a problem that doesn't have that strong of a presence
16:37:06 <sigmavirus24> A) I don't think there's much of a risk
16:37:16 <elmiko> agreed on a)
16:37:48 <elmiko> b) doesn't seem like that big an issue either
16:38:18 <elmiko> so, we'll probably have to discuss this again with etoews and jaypipes, then make a patch to the merge guidelines
16:39:15 <elmiko> it may be possible to do something like sigmavirus24 is suggesting with swapping the block, but that still seems like a solution in search of a problem
16:39:41 <elmiko> well, thanks for talking this through
16:41:07 <elmiko> #topic APIImpact
16:41:15 <elmiko> #link https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
16:41:23 <elmiko> any reviews folks would like to talk about?
16:42:32 * cdent has nothing pressing
16:42:48 <elmiko> i do have an opinion question to ask the group
16:43:14 <elmiko> i'm working on the v2 api for sahara, and i'm curious what are people's thoughts about tenant id in the URI as opposed to in the headers?
16:44:18 <cdent> elmiko: is there any chance that the same under the covers resource would appear for two different tenants or is there strict separation
16:44:48 <cdent> the thing you don't want are two uris for the same thing
16:45:02 <elmiko> hmm, good point
16:45:09 <miguelgrinberg> elmiko: for client-side frameworks it is easier if the URLs are fixed, so not having the project in the URL is better
16:45:21 <elmiko> we have talked about the possibility of sharing clusters between tenants, so that might be something to ocnsider
16:45:46 <sigmavirus24> elmiko: please also look into keystone v3
16:45:50 <sigmavirus24> and how that shapes your designs
16:46:16 <sigmavirus24> you'll want Sahara v2 to behave the same with Keystone v3 or v2 (where tenants are now projects but have a slightly different usecase as well)
16:46:16 <elmiko> sigmavirus24: yea, i'm upgrading everything to sessions now. are you talking about domains and federation?
16:46:33 <sigmavirus24> elmiko: yes, please be conscious of domains, projects, federation, etc.
16:46:56 <elmiko> miguelgrinberg: i'm curious how that makes it easier for client-side stuff
16:47:10 <miguelgrinberg> because they can hardcode them
16:47:21 <sigmavirus24> speaking as someone working on making openstack-ansible do the right things for Keystone v3/Federation it has been awful because services don't do the right things sometimes
16:47:21 <elmiko> sigmavirus24: ok, maybe we'll have to talk sometime abot this, i'm curious about doing that better as well
16:47:36 <elmiko> miguelgrinberg: ah, cool, that makes sense
16:47:51 <sigmavirus24> elmiko: being conscious of the differences are good because you don't want v3 to be shoved into a crack to make it work
16:48:01 <elmiko> sigmavirus24++
16:48:03 <sigmavirus24> then again I don't know much about sahara so
16:48:21 <elmiko> well, know this, we've got some to do ;)
16:48:28 <elmiko> some work*
16:48:55 <cdent> don't we all :(
16:48:59 <cdent> but also :)
16:49:06 <elmiko> thanks for the suggestions all, i've got some more spec work to do around this is what it sounds like
16:49:11 <cdent> the rollercoaster can be a bit confusing
16:49:17 <elmiko> haha, yes
16:49:42 <elmiko> any other business?
16:50:04 <cdent> I just wanted to mention something that might be of interest:
16:50:29 <cdent> sileht has started writing integration tests of aodh, ceilometer, gnocchi and heat all in one gabbi file
16:50:39 <elmiko> ooh neat
16:50:42 <cdent> so purely api driven integration tests across several projects
16:50:46 <cdent> in yaml
16:50:51 <elmiko> that's awesome
16:51:02 <cdent> and since gabb-run can work in a shell pipeline, there's no python required either
16:51:22 <elmiko> is there a link to this?
16:51:29 * cdent is trying to find it
16:52:17 <cdent> but I'm not having much luck
16:52:29 <cdent> (pings to sileht are going unanswered at the moment)
16:52:46 <elmiko> ok, i'd be curious to have a look if you find it
16:52:48 <cdent> anyway: it is clean and clear enough that it might be a useful technique for other folk
16:52:55 <cdent> I'll ping you when I get some more details
16:53:01 <elmiko> great, thanks for bringing it up
16:53:02 <sigmavirus24> also, the artifacts sub-team in glance is working on a new design for v3 of glance's API built on artifacts
16:53:12 <sigmavirus24> they haven't published anything but I'll ping the group when it's published
16:53:12 <elmiko> cool
16:53:22 <cdent> change is afoot!
16:53:29 <elmiko> excelsior!
16:53:30 <sigmavirus24> it still won't have been accepted as a spec though
16:53:40 <sigmavirus24> they were trying to incorporate our first round of feedback
16:53:56 <sigmavirus24> sadly they still haven't talked directly to this group in a meeting or anything though
16:54:28 <elmiko> also, a note, voting for summit presos ends in about 2 hours, if anyone wants to promote an api based talk, please post some links =)
16:54:35 <elmiko> sigmavirus24: =(
16:57:08 <cdent> we seem done
16:57:08 <elmiko> ok then, thanks everybody!
16:57:17 <elmiko> #endmeeting