Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-12-13
05:50:51 openstackgerrit Rajat Dhasmana proposed openstack/python-openstackclient master: Fix: Restore operation returns 'VolumeBackupsRestore' object is not iterable https://review.openstack.org/624860
07:44:08 openstackgerrit machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624873
07:47:57 openstackgerrit machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624874
07:53:00 openstackgerrit machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624875
07:59:33 openstackgerrit machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624879
08:03:11 openstackgerrit machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624880
08:04:05 openstackgerrit machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624881
08:04:13 openstackgerrit Rajat Dhasmana proposed openstack/python-openstackclient master: Fix: Restore operation returns 'VolumeBackupsRestore' object is not iterable https://review.openstack.org/624860
08:08:20 openstackgerrit machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624883
08:09:57 openstackgerrit machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624884
08:11:51 openstackgerrit machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624886
08:12:50 openstackgerrit machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624887
08:38:38 openstackgerrit machunnan proposed openstack/js-openstack-lib master: Capitalizes the first letter -- should to Should https://review.openstack.org/624891
08:43:07 openstackgerrit machunnan proposed openstack/js-openstack-lib master: Capitalizes the first letter -- should to Should https://review.openstack.org/624892
11:53:09 frickler mordred: Shrews: is there any news regarding the dogpile.cache issue to fix broken nodepool jobs?
12:59:08 Shrews frickler: mordred has a review up to requirements to limit the version. and morgan is going to look into the actual dogpile.cache change for us
13:00:02 Shrews that's all i know before coffee
13:09:48 frickler Shrews: thx, found the reqs patch, seems that it needs a bug report/story attached. do we have a simple reproducer yet?
13:12:08 Shrews frickler: i have one. 1 sec
13:17:30 Shrews frickler: http://paste.openstack.org/show/737212/
13:30:55 frickler Shrews: thx, created https://storyboard.openstack.org/#!/story/2004605 from that and will add to the reqs patch
13:31:06 frickler mordred: morgan: ^^ fyi
14:33:00 elmiko edleafe: ack, thanks
14:33:36 edleafe elmiko: it's brief
14:34:17 elmiko yeah, but also contains good info imo
14:34:38 cdent I thought it was elegantly sufficient
14:34:42 elmiko me too
14:34:49 elmiko i like it, no objections here edleafe
14:38:09 edleafe okie dokie
14:42:23 elmiko edleafe: reading it over again, i think the only thing that might make me a tad nervous is that it sounds like we could answer all api related issues that come up. i wonder if that gives the impression that any project-specific api issues are fair game to ask the sig? (maybe i'm reading too much, maybe this isn't a concern)
14:44:05 cdent elmiko: to some extent that's supposed to be what SIG means
14:44:14 cdent we are a house for people who care about APIs
14:44:42 elmiko i guess i meant more like, "hey this call to service X isn't working for me, why not? (insert arcane curl command here)"
14:45:05 elmiko and i imagine we would definitely point that person in the right direction
14:45:15 cdent "hey caller, it looks like you're using nova, you might want to talk to ..."
14:45:25 elmiko anyways, it was just a thought. i don't think it's a concern, but if i pushed to make a critique.
14:45:32 elmiko yeah
14:45:52 elmiko i still don't have an objection, i was just trying to go deeper with due diligence =)
14:51:15 edleafe elmiko: Sorry, was afk
14:51:47 edleafe I can see what you mean, but I kinda think that's a good thing. The more interest in the SIG, the better
14:52:16 elmiko i like that attitude =)
14:52:17 edleafe Like cdent said, we may not have the answers, but we might help point people to better resources
14:52:25 elmiko agreed
14:56:41 elmiko thanks for indulging me ;)
15:11:57 cdent elmiko: speaking of indulgences, how did your aqua vit settle in at home. did it even make it home?
15:12:31 elmiko haha, yes! it made it home
15:12:35 elmiko it's been a big hit =)
15:13:02 elmiko people are becoming scared at the volume of clear liquors i am pushing on them when they visit XD
15:13:35 cdent here, try this mysterious thing!
15:23:49 elmiko basically
15:24:31 elmiko at least with the eau de vie they kinda get it, but when i start digging out stuff slike slivovice and awamori things get /interesting/ =D
15:25:24 elmiko the liquor cabinet is starting to look a little nuts though, like "does this guy have a problem?" haha
16:00:17 edleafe API-SIG Office Hour has begun
16:00:43 edleafe Get your feet off the table!! Were you raised in a barn?
16:01:38 elmiko sadly no, just a normal house
16:03:10 edleafe dtantsur: around? Wanted to get your feedback on http://paste.openstack.org/show/737157/
16:03:32 edleafe It's the little blurb for the OpenStack Foundation Annual Report about our SIG
16:03:58 dtantsur edleafe: sounds perfect to me
16:04:16 edleafe kewl
16:04:51 dtantsur also JFYI I'm off starting tomorrow, back in Jan
16:04:51 edleafe The only other issue I had was whether to freeze https://review.openstack.org/#/c/616610/
16:05:01 edleafe lucky you!
16:05:19 edleafe I'm around all next week, then back 2nd week of Jan
16:05:58 elmiko i'll be around next week as well
16:07:25 edleafe dtantsur: so you would prefer to interpret DELETE as "find this resource, and then delete it"
16:07:48 edleafe instead of "make sure this resource doesn't exist"
16:07:56 dtantsur edleafe: "delete this resource", yes
16:09:01 dtantsur I think if somebody is actually going to follow this guideline, it's going to be confusing for users
16:09:15 dtantsur e.g. `rm /foo` actually errors out
16:10:48 edleafe So consider this scenario: resource `foo` exists. Two users call DELETE /rsrc/foo. One should get 204, and the other 404?
16:13:04 dtantsur right
16:14:36 elmiko i think the only weird part to me is how long should that behavior persist after the delete?
16:14:54 kmalloc Shrews: now that my massive headache of doom has passed, i should be able to look at dogpile and the other issues outstanding
16:15:02 elmiko like, if i delete a resources ages ago, when should the server respond with a 404?
16:15:04 kmalloc Shrews, mordred: ^ thanks for bearing with me yesterday.
16:15:34 elmiko or should it ever? which implies keeping track of delete resources for the purposes of delete responses
16:15:54 edleafe RFC 7231 says that DELETE is idempotent: https://tools.ietf.org/html/rfc7231#section-8.1.3
16:15:56 dtantsur tracking deleting resources is quite a change to many database models
16:16:41 dtantsur edleafe: that's one of the reasons HTTP is not a great match for API..
16:17:03 kmalloc edleafe: oh good to know.
16:17:15 kmalloc edleafe: also... damn that means keystone has messed up a bunch.
16:18:07 elmiko edleafe: such a weird knot this is, it should be idempotent, but does that mean it should always return some 2XX for a previously deleted resource?
16:18:33 elmiko i mean, i know that's what we are proposing i'm just exploring the idea a little more
16:18:40 dtantsur yeah, this is a weird point
16:19:11 elmiko definitely
16:19:22 edleafe The impetus for adding this guideline is that it is assumed that an API has one implementation, but many, many consumers. Attempting to delete a resource that doesn't exist requires an exception handler. If you can return a 404 from the API, every single consumer of that API has to build code to handle that
16:19:36 edleafe elmiko: why not?
16:19:54 edleafe "I don't want resource foo to exist" "OK, it doesn't exist"
16:20:06 dtantsur "In effect, this method is similar to the rm command
16:20:09 dtantsur in UNIX: it expresses a deletion operation on the URI mapping of the
16:20:10 dtantsur origin server rather than an expectation that the previously
16:20:12 dtantsur associated information be deleted.
16:20:21 dtantsur I don't know how to interpret it..
16:20:25 elmiko edleafe: it just makes me wonder what the impl starts to look like, for example do i need to keep a database table of delete resources to properly respond to all future delete requests?
16:20:40 dtantsur edleafe: the "very single customer" is simply incorrect
16:20:40 edleafe elmiko: why?
16:20:53 elmiko if i delete some resource /foo/bar
16:21:09 dtantsur I personally very rarely catch 404 from deletions because I *want* to know that something went south
16:21:15 elmiko then later a request comes in to DELETE /foo/bar, then i need to respond 2XX if it has been deleted. is that accurate?
16:22:25 edleafe elmiko: if you call DELETE /foo/bar, and `foo` is a valid resouce class, you return 204 whether or not you had to delete resource `bar` or not. You don't need to confirm that `bar` ever existed.

Earlier   Later