| *** mriedem has quit IRC | 00:01 | |
| *** bobh has joined #openstack-sdks | 00:19 | |
| *** tosky has quit IRC | 00:55 | |
| *** dave-mccowan has joined #openstack-sdks | 01:18 | |
| *** dave-mccowan has quit IRC | 02:14 | |
| *** Blotis has joined #openstack-sdks | 02:36 | |
| *** bobh has quit IRC | 02:37 | |
| *** bobh has joined #openstack-sdks | 02:38 | |
| *** bobh has quit IRC | 02:42 | |
| *** Blotis has left #openstack-sdks | 02:57 | |
| *** bobh has joined #openstack-sdks | 03:38 | |
| *** bobh has quit IRC | 03:39 | |
| *** bobh has joined #openstack-sdks | 03:40 | |
| *** bobh has quit IRC | 03:40 | |
| *** bobh has joined #openstack-sdks | 03:41 | |
| *** bobh has quit IRC | 03:57 | |
| *** jkulik has quit IRC | 04:02 | |
| openstackgerrit | Rajat Dhasmana proposed openstack/python-openstackclient master: Fix: Restore operation returns 'VolumeBackupsRestore' object is not iterable https://review.openstack.org/624860 | 05:50 |
|---|---|---|
| *** slaweq has joined #openstack-sdks | 06:57 | |
| *** Luzi has joined #openstack-sdks | 07:33 | |
| openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624873 | 07:44 |
| openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624874 | 07:47 |
| openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624875 | 07:53 |
| openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624879 | 07:59 |
| openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624880 | 08:03 |
| openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624881 | 08:04 |
| openstackgerrit | Rajat Dhasmana proposed openstack/python-openstackclient master: Fix: Restore operation returns 'VolumeBackupsRestore' object is not iterable https://review.openstack.org/624860 | 08:04 |
| openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624883 | 08:08 |
| openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624884 | 08:09 |
| openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624886 | 08:11 |
| openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624887 | 08:12 |
| openstackgerrit | machunnan proposed openstack/js-openstack-lib master: Capitalizes the first letter -- should to Should https://review.openstack.org/624891 | 08:38 |
| openstackgerrit | machunnan proposed openstack/js-openstack-lib master: Capitalizes the first letter -- should to Should https://review.openstack.org/624892 | 08:43 |
| *** jpena|off is now known as jpena | 09:04 | |
| *** ttsiouts has joined #openstack-sdks | 09:18 | |
| *** jpich has joined #openstack-sdks | 09:19 | |
| *** gtema has joined #openstack-sdks | 09:25 | |
| *** ttsiouts has quit IRC | 09:28 | |
| *** ttsiouts has joined #openstack-sdks | 09:29 | |
| *** ttsiouts has quit IRC | 09:33 | |
| *** noama has joined #openstack-sdks | 09:35 | |
| *** tosky has joined #openstack-sdks | 09:37 | |
| *** ttsiouts has joined #openstack-sdks | 09:40 | |
| *** e0ne has joined #openstack-sdks | 09:41 | |
| *** markvoelker has joined #openstack-sdks | 09:46 | |
| *** gtema has quit IRC | 10:01 | |
| *** cdent has joined #openstack-sdks | 10:42 | |
| *** ttsiouts has quit IRC | 10:51 | |
| *** ttsiouts has joined #openstack-sdks | 10:52 | |
| *** dtantsur|afk is now known as dtantsur | 10:53 | |
| *** ttsiouts has quit IRC | 10:57 | |
| *** tobias-urdin is now known as tobias-urdin_afk | 11:41 | |
| *** tobias-urdin_afk is now known as tobias-urdin | 11:42 | |
| *** tobias-urdin is now known as tobias-urdin_afk | 11:43 | |
| frickler | mordred: Shrews: is there any news regarding the dogpile.cache issue to fix broken nodepool jobs? | 11:53 |
| *** markvoelker has quit IRC | 12:24 | |
| *** gtema has joined #openstack-sdks | 12:36 | |
| *** mriedem has joined #openstack-sdks | 12:42 | |
| *** e0ne has quit IRC | 12:51 | |
| *** tobias-urdin_afk is now known as tobias-urdin | 12:53 | |
| 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 | 12:59 |
| Shrews | that's all i know before coffee | 13:00 |
| *** gtema has quit IRC | 13:00 | |
| *** jpena is now known as jpena|lunch | 13:01 | |
| *** bobh has joined #openstack-sdks | 13:04 | |
| frickler | Shrews: thx, found the reqs patch, seems that it needs a bug report/story attached. do we have a simple reproducer yet? | 13:09 |
| *** markvoelker has joined #openstack-sdks | 13:10 | |
| Shrews | frickler: i have one. 1 sec | 13:12 |
| Shrews | frickler: http://paste.openstack.org/show/737212/ | 13:17 |
| *** bobh has quit IRC | 13:18 | |
| frickler | Shrews: thx, created https://storyboard.openstack.org/#!/story/2004605 from that and will add to the reqs patch | 13:30 |
| frickler | mordred: morgan: ^^ fyi | 13:31 |
| *** e0ne has joined #openstack-sdks | 13:35 | |
| *** e0ne has quit IRC | 13:49 | |
| *** irclogbot_2 has quit IRC | 13:50 | |
| *** tosky has quit IRC | 13:56 | |
| *** e0ne has joined #openstack-sdks | 13:57 | |
| *** bobh has joined #openstack-sdks | 13:58 | |
| *** tosky has joined #openstack-sdks | 14:00 | |
| *** markvoelker has quit IRC | 14:03 | |
| *** irclogbot_2 has joined #openstack-sdks | 14:10 | |
| *** irclogbot_2 has quit IRC | 14:19 | |
| *** bobh has quit IRC | 14:27 | |
| *** ttsiouts has joined #openstack-sdks | 14:28 | |
| elmiko | edleafe: ack, thanks | 14:33 |
| *** irclogbot_2 has joined #openstack-sdks | 14:33 | |
| edleafe | elmiko: it's brief | 14:33 |
| elmiko | yeah, but also contains good info imo | 14:34 |
| cdent | I thought it was elegantly sufficient | 14:34 |
| elmiko | me too | 14:34 |
| elmiko | i like it, no objections here edleafe | 14:34 |
| *** markvoelker has joined #openstack-sdks | 14:36 | |
| edleafe | okie dokie | 14:38 |
| 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:42 |
| *** dayou has quit IRC | 14:43 | |
| cdent | elmiko: to some extent that's supposed to be what SIG means | 14:44 |
| cdent | we are a house for people who care about APIs | 14:44 |
| 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:44 |
| elmiko | and i imagine we would definitely point that person in the right direction | 14:45 |
| cdent | "hey caller, it looks like you're using nova, you might want to talk to ..." | 14:45 |
| * cdent puts on his paperclip costume | 14:45 | |
| 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 |
| elmiko | yeah | 14:45 |
| elmiko | i still don't have an objection, i was just trying to go deeper with due diligence =) | 14:45 |
| edleafe | elmiko: Sorry, was afk | 14:51 |
| 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:51 |
| elmiko | i like that attitude =) | 14:52 |
| edleafe | Like cdent said, we may not have the answers, but we might help point people to better resources | 14:52 |
| elmiko | agreed | 14:52 |
| elmiko | thanks for indulging me ;) | 14:56 |
| *** dayou has joined #openstack-sdks | 15:00 | |
| cdent | elmiko: speaking of indulgences, how did your aqua vit settle in at home. did it even make it home? | 15:11 |
| elmiko | haha, yes! it made it home | 15:12 |
| elmiko | it's been a big hit =) | 15:12 |
| elmiko | people are becoming scared at the volume of clear liquors i am pushing on them when they visit XD | 15:13 |
| cdent | here, try this mysterious thing! | 15:13 |
| elmiko | basically | 15:23 |
| 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:24 |
| elmiko | the liquor cabinet is starting to look a little nuts though, like "does this guy have a problem?" haha | 15:25 |
| *** markvoelker has quit IRC | 15:38 | |
| *** Luzi has quit IRC | 15:52 | |
| *** bobh has joined #openstack-sdks | 15:53 | |
| *** ttsiouts has quit IRC | 15:56 | |
| *** ttsiouts has joined #openstack-sdks | 15:57 | |
| * elmiko sets down coffee mug | 16:00 | |
| edleafe | API-SIG Office Hour has begun | 16:00 |
| * elmiko rests feet on table | 16:00 | |
| edleafe | Get your feet off the table!! Were you raised in a barn? | 16:00 |
| * elmiko pulls feet down | 16:01 | |
| elmiko | sadly no, just a normal house | 16:01 |
| edleafe | dtantsur: around? Wanted to get your feedback on http://paste.openstack.org/show/737157/ | 16:03 |
| edleafe | It's the little blurb for the OpenStack Foundation Annual Report about our SIG | 16:03 |
| * dtantsur reads | 16:03 | |
| dtantsur | edleafe: sounds perfect to me | 16:03 |
| edleafe | kewl | 16:04 |
| edleafe | The only other issue I had was whether to freeze https://review.openstack.org/#/c/616610/ | 16:04 |
| dtantsur | also JFYI I'm off starting tomorrow, back in Jan | 16:04 |
| edleafe | lucky you! | 16:05 |
| edleafe | I'm around all next week, then back 2nd week of Jan | 16:05 |
| elmiko | i'll be around next week as well | 16:05 |
| * dtantsur has stated his opinion re 616610 | 16:06 | |
| edleafe | dtantsur: so you would prefer to interpret DELETE as "find this resource, and then delete it" | 16:07 |
| edleafe | instead of "make sure this resource doesn't exist" | 16:07 |
| dtantsur | edleafe: "delete this resource", yes | 16:07 |
| *** jpena|lunch is now known as jpena | 16:08 | |
| dtantsur | I think if somebody is actually going to follow this guideline, it's going to be confusing for users | 16:09 |
| dtantsur | e.g. `rm /foo` actually errors out | 16:09 |
| *** morgan is now known as kmalloc | 16:09 | |
| edleafe | So consider this scenario: resource `foo` exists. Two users call DELETE /rsrc/foo. One should get 204, and the other 404? | 16:10 |
| dtantsur | right | 16:13 |
| elmiko | i think the only weird part to me is how long should that behavior persist after the delete? | 16:14 |
| 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:14 |
| elmiko | like, if i delete a resources ages ago, when should the server respond with a 404? | 16:15 |
| kmalloc | Shrews, mordred: ^ thanks for bearing with me yesterday. | 16:15 |
| elmiko | or should it ever? which implies keeping track of delete resources for the purposes of delete responses | 16:15 |
| edleafe | RFC 7231 says that DELETE is idempotent: https://tools.ietf.org/html/rfc7231#section-8.1.3 | 16:15 |
| dtantsur | tracking deleting resources is quite a change to many database models | 16:15 |
| *** ttsiouts has quit IRC | 16:16 | |
| dtantsur | edleafe: that's one of the reasons HTTP is not a great match for API.. | 16:16 |
| * dtantsur shrugs | 16:16 | |
| kmalloc | edleafe: oh good to know. | 16:17 |
| kmalloc | edleafe: also... damn that means keystone has messed up a bunch. | 16:17 |
| * kmalloc makes note for v4.. when that comes. | 16:17 | |
| 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 |
| elmiko | i mean, i know that's what we are proposing i'm just exploring the idea a little more | 16:18 |
| dtantsur | yeah, this is a weird point | 16:18 |
| elmiko | definitely | 16:19 |
| 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 |
| edleafe | elmiko: why not? | 16:19 |
| edleafe | "I don't want resource foo to exist" "OK, it doesn't exist" | 16:19 |
| dtantsur | "In effect, this method is similar to the rm command | 16:20 |
| dtantsur | in UNIX: it expresses a deletion operation on the URI mapping of the | 16:20 |
| dtantsur | origin server rather than an expectation that the previously | 16:20 |
| dtantsur | associated information be deleted. | 16:20 |
| dtantsur | I don't know how to interpret it.. | 16:20 |
| 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 |
| edleafe | elmiko: why? | 16:20 |
| dtantsur | edleafe: the "very single customer" is simply incorrect | 16:20 |
| elmiko | if i delete some resource /foo/bar | 16:20 |
| dtantsur | I personally very rarely catch 404 from deletions because I *want* to know that something went south | 16:21 |
| 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:21 |
| 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. | 16:22 |
| edleafe | dtantsur: that's very different than "I want this resource gone" | 16:23 |
| edleafe | dtantsur: if you care that it's there and getting deleted, do a GET/HEAD on it first | 16:23 |
| dtantsur | well, "I want this resource gone" is not the semantic I use, so no wonder :) | 16:23 |
| elmiko | edleafe: what if "bar" never existed as a foo? | 16:23 |
| elmiko | shouldn't that be a 404? | 16:23 |
| edleafe | elmiko: No | 16:23 |
| dtantsur | edleafe: so instead of handling 404 by some consumers, some other consumers have to make 2 requests? | 16:23 |
| elmiko | ah, i misunderstood you then | 16:24 |
| edleafe | if you interpret delete as "I don't want resource bar to exist" | 16:24 |
| *** noama has quit IRC | 16:24 | |
| dtantsur | then we should allow 'DELETE /some/nonsense' :) | 16:24 |
| dtantsur | half-kidding, but the same logic can be applied to invalid URLs | 16:24 |
| edleafe | If you care about the existence of a resource, you call GET or HEAD | 16:24 |
| kmalloc | it's fine to say DELETE X and if the path is unrouted, get a 404 | 16:24 |
| kmalloc | afaict. | 16:25 |
| kmalloc | acutally | 16:25 |
| kmalloc | no | 16:25 |
| dtantsur | kmalloc: why? I want it to be gone, and it's gone | 16:25 |
| edleafe | dtantsur: cdent clarified that. Just what kmalloc said | 16:25 |
| kmalloc | that would be a method not allowed | 16:25 |
| kmalloc | sorry, wrong error | 16:25 |
| dtantsur | edleafe: not for me | 16:25 |
| kmalloc | not 404, 40.. 405? | 16:25 |
| elmiko | kmalloc: if it's possible that the resource _could_ have existed, then it should 404. if i understand edleafe's point | 16:25 |
| elmiko | er should not! | 16:25 |
| elmiko | sorry | 16:25 |
| kmalloc | elmiko: right | 16:25 |
| * dtantsur starts leaning toward a proper -1 now | 16:26 | |
| kmalloc | elmiko: it should be .. 200/204/2XX (not 201) | 16:26 |
| elmiko | right | 16:26 |
| edleafe | Generally 204 is returned from DELETE | 16:26 |
| kmalloc | if delete is not allowed, e.g. the whole path is unrouted in an api | 16:26 |
| edleafe | There is no response body | 16:26 |
| kmalloc | XXXX/<resource> -> where XXXX is not a thing at all | 16:26 |
| kmalloc | that should be 405 | 16:26 |
| kmalloc | as DELETE is not supported | 16:27 |
| kmalloc | but if XXXX is a thing, and there could be a resource under it | 16:27 |
| edleafe | kmalloc: according to cdent, it's 404 | 16:27 |
| dtantsur | what about GET XXXX? | 16:27 |
| * edleafe keeps hoping to invoke the spirit of cdent with these repeated incantation | 16:27 | |
| kmalloc | edleafe: in most of openstack 404 is a thing. | 16:27 |
| cdent | sorry, I'm debugging a gate failure | 16:27 |
| kmalloc | most of openstack is wrong | 16:27 |
| kmalloc | from a standpoint of the RFC | 16:27 |
| edleafe | dtantsur: GET /XXXX should also be 404 | 16:28 |
| cdent | only if XXXXX/<resource> has any methods at all should it ever be a 405 on delete | 16:28 |
| cdent | if it simply does not exist then it should be 404 | 16:28 |
| kmalloc | hm. | 16:28 |
| kmalloc | i could see that interpretation | 16:28 |
| dtantsur | kmalloc: well, we're talking of taking an RFC designed for hypertext and applying it to API | 16:28 |
| kmalloc | order of precidence on routing | 16:28 |
| cdent | kmalloc: that interpretation is right :) | 16:28 |
| edleafe | From the front page of our guidelines: "Note Where this guidance is incomplete or ambiguous, refer to the HTTP RFCs—RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, and RFC 7235—as the ultimate authority." | 16:28 |
| dtantsur | this has gone wrong many times, this is no exception | 16:28 |
| cdent | the URI is the primary thing | 16:28 |
| kmalloc | XXX is checked before XXXX/YYYY | 16:29 |
| kmalloc | so, XXX hits 404 | 16:29 |
| kmalloc | sure. | 16:29 |
| cdent | if there is _nothing_ that has that URI, then 404 | 16:29 |
| cdent | if you can GET it, but can't delete it, then 405 | 16:29 |
| kmalloc | but a 404 on a delete where a resource could exist is explictly wrong | 16:29 |
| kmalloc | it's always a success if delete could work | 16:30 |
| *** e0ne has quit IRC | 16:30 | |
| kmalloc | cdent: ++ don't have to convince me too hard on that front :P | 16:30 |
| cdent | that's effectively what ed's thing say | 16:30 |
| edleafe | kmalloc: that's what the point of https://review.openstack.org/#/c/616610/ is | 16:30 |
| edleafe | jinx | 16:30 |
| kmalloc | hehe | 16:30 |
| cdent | if this is a valid uri, and there might have been a thing here, or ever will be, respond 204 on delete when it is not there, or has just been removed | 16:30 |
| kmalloc | yep. | 16:30 |
| cdent | but if the url is invalid because you can't even GET there, then 404 | 16:30 |
| *** e0ne has joined #openstack-sdks | 16:30 | |
| cdent | s/even/ever/ | 16:30 |
| kmalloc | yes. | 16:30 |
| kmalloc | i could see that, i'll have to go poke and see how flask handles it | 16:31 |
| kmalloc | i think it does it the correct way | 16:31 |
| kmalloc | what you just described | 16:31 |
| kmalloc | because if not, i have some bugs to go open/fix | 16:31 |
| elmiko | edleafe: fwiw, i'm still +1 on the review | 16:31 |
| * edleafe wipes brow | 16:31 | |
| elmiko | lol | 16:31 |
| elmiko | seems like dtantsur will be the -1 | 16:31 |
| dtantsur | yep | 16:32 |
| edleafe | One thing to keep in mind before you -1: | 16:32 |
| edleafe | This is a guideline; it says what projects should ideally follow | 16:32 |
| edleafe | We are trying to encourage new projects to follow them. Existing projects do not have to change | 16:33 |
| kmalloc | i know if we iterate on the keystone api like I want to, we'll get to where we're more closely following the guidelines | 16:34 |
| kmalloc | we just have a ton of history that... well we can't "just fix" | 16:34 |
| edleafe | kmalloc: sure, that's reasonable. | 16:34 |
| elmiko | kmalloc: totally understandable | 16:34 |
| elmiko | to echo edleafe, these are guidelines and not laws | 16:34 |
| kmalloc | also we don't have (and doesn't look like we will in the near-to-medium term) microversions :) | 16:34 |
| kmalloc | also +1 on that change. I like the guidelines | 16:35 |
| edleafe | kmalloc: the other purpose of the guidelines is to "settle arguments". If a change is being considered, and there are differing views, the guidelines can be used as an arbiter | 16:35 |
| elmiko | imo, microversions seem less contentious. but i'm just one person | 16:35 |
| edleafe | elmiko: lol | 16:35 |
| elmiko | edleafe ++ | 16:35 |
| kmalloc | i'd like to really outline the use of 405 in that doc. | 16:35 |
| kmalloc | because it is useful. | 16:35 |
| kmalloc | but that is a bigger bundle of "lots of comments" | 16:35 |
| dtantsur | microversions are not contentious at all, just do them | 16:35 |
| * dtantsur ducks | 16:35 | |
| elmiko | dtantsur: LOL | 16:36 |
| kmalloc | dtantsur: ok, go implement it for keystone, i think you just volunteered :) :P :P :P | 16:36 |
| edleafe | kmalloc: http://specs.openstack.org/openstack/api-sig/guidelines/http/response-codes.html#failure-code-clarifications | 16:36 |
| dtantsur | how many years it took us to implement proper negotiation in OSC? oh wait, it's still not there? :) | 16:36 |
| edleafe | There is a paragraph there on 405 | 16:36 |
| kmalloc | edleafe: yes, but i think that needs some expansion | 16:36 |
| edleafe | patches welcome! :) | 16:37 |
| kmalloc | yes, it's on my long long long list | 16:37 |
| kmalloc | :) | 16:37 |
| dtantsur | kmalloc: I'll switch keystone to SOAP | 16:37 |
| kmalloc | dtantsur: if you can get people to approve it... and not break our API contracts, go for it | 16:37 |
| kmalloc | dtantsur: i'll even volunteer to not -2 that change | 16:37 |
| kmalloc | or even -1 it. | 16:37 |
| edleafe | I think we should add a guideline that recommends abandoning the term "microversions", and replaces it with "every change is a major version" | 16:37 |
| dtantsur | SOAP never greaks contracts, it's enterprise-grade | 16:37 |
| dtantsur | edleafe: /me imagines $ curl https://baremetal.example.com/v56/nodes | 16:38 |
| dtantsur | it's mostly kidding again, but I do feel bad that we break RESTfulness with microversions | 16:38 |
| * elmiko shudders at the mention of SOAP | 16:40 | |
| dtantsur | hehe | 16:40 |
| elmiko | but then i am a smelly hippy, so there is that XD | 16:40 |
| dtantsur | I got some funny experience with it | 16:40 |
| elmiko | if you had "fun" anywhere near SOAP then you are doing better than most ;) | 16:40 |
| dtantsur | It's supposed to be interoperable, but in fact I could not make a SOAP client in Java talk to a SOAP server in Python | 16:40 |
| elmiko | ouch | 16:40 |
| dtantsur | they had different SOAPs apparently | 16:40 |
| elmiko | LOL | 16:40 |
| edleafe | I made a python SOAP server talk with a .NET client | 16:41 |
| dtantsur | nice! | 16:41 |
| * edleafe remembers when XML was going to solve all our problems | 16:42 | |
| dtantsur | yeah, except for the problem "how to serialize a list". this one is unsolvable. something between "what's the point of life" and "where is my 2nd sock". | 16:42 |
| cdent | dtantsur: which of many aspect of REST do we break with microversions. I suspect we could come up with several depending on which rules we wanted follow | 16:42 |
| cdent | dtantsur: also I'm pleased to see you sticking to your guns with -1 the DELETE thing. I think it is important to get it not just right but agreed on and you raise some good points. | 16:43 |
| dtantsur | cdent: the one where a URI points to a resource. with microversions a URL can mean anything (or nothing at all) depending on a header | 16:43 |
| dtantsur | :) | 16:43 |
| *** tosky has quit IRC | 16:43 | |
| dtantsur | e.g. I cannot say /v1/portgroups/<UUID> is a representation of a portgroup <UUID> | 16:43 |
| dtantsur | because it's only the case if microversion>=1.<something> | 16:44 |
| *** tosky has joined #openstack-sdks | 16:44 | |
| * edleafe dislikes versions in both URI and header | 16:44 | |
| elmiko | edleafe: heh, xml actually /solving/ problems... XD | 16:44 |
| dtantsur | this defeats e.g. the "Location" header to a degree, since "Location" is meaningless without a microversion to use it with | 16:45 |
| dtantsur | edleafe: I guess from the pure RESTful point of view we had to put them in the URL somewhere.. I know that it has other problems :) | 16:45 |
| cdent | dtantsur: yeah, I feel really bad about URIs that exist in microversion N+1 but not N. It's dirty. | 16:46 |
| edleafe | I believe that the original practice of using /v1-type URLs was because the original OpenStack devs always did it that way, and so continued the practice. It was never debated | 16:46 |
| cdent | their existence has allowed us to get away with some things that we would have considered much more strongly if they didn't | 16:47 |
| cdent | until placement, yo | 16:47 |
| * cdent tried to resist microversions in placement too | 16:47 | |
| edleafe | cdent: that's why I really hate the term "microversion". It's anything but micro | 16:47 |
| cdent | really-hugeo-version | 16:47 |
| edleafe | megaversion | 16:47 |
| edleafe | or, you know, "version" | 16:48 |
| dtantsur | if we were less hipster, we would just use "API version" | 16:48 |
| dtantsur | ha! | 16:48 |
| elmiko | cdent: lol | 16:48 |
| edleafe | the only difference with microversions is that we simultaneously support many, many possible versions | 16:48 |
| elmiko | i like "really-hugeo-version", it has a nice ring to it. would make debates much more lively | 16:49 |
| elmiko | but, i am a fan of absurdism | 16:50 |
| dtantsur | then we also have to be creative with numbers themselves | 16:51 |
| elmiko | ooh, nice | 16:52 |
| edleafe | we should use random integers for our versions. | 16:53 |
| dtantsur | what about multiplying 3.14 by 1.X where X is a number of changed strings in the patch introducing the microversion? | 16:53 |
| edleafe | dtantsur: too much work | 16:53 |
| edleafe | We could just follow git's lead and make the version a hash of the codebase | 16:54 |
| *** jpich has quit IRC | 16:54 | |
| elmiko | edleafe: haha, <3 random integers | 16:55 |
| dtantsur | nice! it will add a pleasant task of figuring out how to put a hash in the file being hashed | 16:55 |
| dtantsur | or we could get boring and use the current date and time | 16:55 |
| elmiko | i love it, we can have a new middle to handle to upgrade that all projects must follow to become compliant with the new randoversions | 16:55 |
| elmiko | *middleware | 16:55 |
| edleafe | dtantsur: no problem. Internally you do a 'git checkout {hash}' and then run the request through that | 16:55 |
| elmiko | hahaha | 16:56 |
| edleafe | simple! | 16:56 |
| elmiko | really randoversioning is an upgrade, because it helps project maintainers know who is _really_ following the project | 16:56 |
| elmiko | "i'm using the latest, version 3831923", "ah ah, didn't you know the latest is actually 92359841?!?" | 16:57 |
| elmiko | busted! | 16:57 |
| edleafe | So not only could we replace 'latest' with 'HEAD', we now have access to 'HEAD^', 'HEAD^^', etc | 16:58 |
| dtantsur | folks, you keep forgetting that in year 2018 we *must* be mobile-friendly | 16:58 |
| dtantsur | so I recommend we start using smiles in versions | 16:58 |
| dtantsur | * smileys | 16:59 |
| edleafe | Better yet: animojis! | 16:59 |
| elmiko | haha, perfect | 17:00 |
| edleafe | https://emojipedia-us.s3.amazonaws.com/content/2017/09/21/animoji-poo-emojipedia.gif | 17:00 |
| elmiko | dtantsur: micromoji-versioning? | 17:00 |
| edleafe | I guess our office hour is up. | 17:00 |
| elmiko | ah well | 17:00 |
| dtantsur | right! | 17:00 |
| elmiko | have a good weekend y'all =) | 17:01 |
| dtantsur | see you in January :) | 17:01 |
| dtantsur | happy holidays | 17:01 |
| elmiko | enjoy dtantsur ! | 17:01 |
| edleafe | elmiko: mobile devices are getting bigger, so let's not use 'micro' | 17:01 |
| elmiko | edleafe: good point | 17:01 |
| edleafe | See ya, dtantsur! Enjoy your time off! | 17:01 |
| *** bobh has quit IRC | 17:01 | |
| * cdent blinks | 17:02 | |
| edleafe | cdent: So are you on board with replacing versions with git hashes? | 17:03 |
| cdent | only if we do the git checkout bit internally, and only from a remote repo | 17:04 |
| *** bobh has joined #openstack-sdks | 17:05 | |
| edleafe | If we put versions in the URI, we could have GET /v91b735fddedbeb9d1cc241dadc753ff2f3b86a4b/foo/bar | 17:05 |
| edleafe | Users would love that! | 17:06 |
| cdent | that looks suspiciously similar to user/project/tenant/whatever it was in URIs | 17:06 |
| cdent | which was an equally bad idea | 17:06 |
| elmiko | i'm gonna grab some lunch, catch you gents later o/ | 17:07 |
| *** bobh has quit IRC | 17:10 | |
| *** bobh has joined #openstack-sdks | 17:12 | |
| *** bobh has quit IRC | 17:16 | |
| *** dtantsur is now known as dtantsur|afk | 17:27 | |
| *** bobh has joined #openstack-sdks | 17:51 | |
| *** e0ne has quit IRC | 18:11 | |
| *** e0ne has joined #openstack-sdks | 18:15 | |
| *** e0ne has quit IRC | 18:16 | |
| *** jpena is now known as jpena|off | 18:38 | |
| *** e0ne has joined #openstack-sdks | 19:53 | |
| *** tosky has quit IRC | 19:56 | |
| *** tosky has joined #openstack-sdks | 19:57 | |
| *** e0ne has quit IRC | 19:58 | |
| *** gtema has joined #openstack-sdks | 20:12 | |
| *** bobh has quit IRC | 20:28 | |
| *** bobh has joined #openstack-sdks | 20:48 | |
| *** bobh has quit IRC | 20:52 | |
| *** mriedem has quit IRC | 21:02 | |
| openstackgerrit | Thomas Bechtold proposed openstack/openstacksdk master: Drop self.conn from base.TestCase https://review.openstack.org/625115 | 21:07 |
| *** markvoelker has joined #openstack-sdks | 21:11 | |
| *** gtema has quit IRC | 21:11 | |
| *** mriedem has joined #openstack-sdks | 21:26 | |
| *** tobias-urdin has quit IRC | 21:32 | |
| *** bobh has joined #openstack-sdks | 21:54 | |
| *** bobh has quit IRC | 22:00 | |
| *** markvoelker has quit IRC | 22:06 | |
| *** bobh has joined #openstack-sdks | 22:15 | |
| *** lbragstad has quit IRC | 22:37 | |
| kmalloc | mordred: the SDK issue, are you seeing that on master or on pip isntalled? | 23:08 |
| kmalloc | mordred: because i can't duplicate it on the current release | 23:08 |
| kmalloc | mordred: the discovery bit | 23:08 |
| kmalloc | mordred: i just tried with vexxhost: | 23:09 |
| kmalloc | https://www.irccloud.com/pastebin/EHIjvSgI/ | 23:09 |
| kmalloc | mordred: using pretty much your code: | 23:10 |
| kmalloc | https://www.irccloud.com/pastebin/7mR8Gonv/ | 23:10 |
| kmalloc | mordred: i omitted the auth request. | 23:10 |
| kmalloc | maybe you're hitting the unversioned URL? | 23:11 |
| kmalloc | nope, also not seeing that there. | 23:11 |
| Shrews | kmalloc: you gotta enable the cache part | 23:12 |
| kmalloc | Shrews: bah. | 23:13 |
| Shrews | kmalloc: steps to reproduce are here: https://storyboard.openstack.org/#!/story/2004605 | 23:13 |
| Shrews | kmalloc: unless there is a different issue you are talking about :) | 23:13 |
| kmalloc | no different thing | 23:13 |
| Shrews | oh, sorry | 23:13 |
| kmalloc | Shrews: i was looking at the duplicate discovery bit first | 23:13 |
| kmalloc | Shrews: and i can't duplicate that. | 23:13 |
| kmalloc | since that one might be something wrong in KSA. | 23:13 |
| Shrews | kmalloc: i am no help there | 23:14 |
| kmalloc | yeah, will need mordred to weigh in on duplication, it just isn't happening for me. | 23:14 |
| kmalloc | on to the dogpile thing. | 23:14 |
| ianw | kmalloc: yeah, i'm taking a look at it too ... wow it's hairy | 23:18 |
| ianw | the change is https://gerrit.sqlalchemy.org/#/c/sqlalchemy/dogpile.cache/+/996/4/dogpile/cache/region.py | 23:19 |
| ianw | i can sort of replicate it. i think in the unit tests, somehow it's getting eaten | 23:20 |
| ianw | but if you put more failures in there, you see it | 23:20 |
| kmalloc | Shrews: on another unrelated note | 23:22 |
| kmalloc | https://usercontent.irccloud-cdn.com/file/ylihsQes/battlestation | 23:23 |
| kmalloc | Shrews: ^ hehehe 3x portrait mode monitors = win for code! | 23:23 |
| kmalloc | ianw: yeah it's weird. | 23:24 |
| Shrews | kmalloc: sick | 23:25 |
| *** tosky has quit IRC | 23:27 | |
| kmalloc | Shrews: i'm not able to duplicate that issue | 23:33 |
| kmalloc | with dogpile 0.7.0 or 0.7.1 | 23:33 |
| kmalloc | i must have something broken in my clouds.yaml | 23:33 |
| kmalloc | ooh wait. | 23:34 |
| kmalloc | nope. hmmm. | 23:35 |
| kmalloc | there we go | 23:37 |
| kmalloc | hmm. this is why i usually use settr() instead of = for setting values, especially on python structures. | 23:39 |
| *** slaweq has quit IRC | 23:40 | |
| *** mriedem has quit IRC | 23:41 | |
| ianw | so the original decorator wrapped the function, which is actually in this case a bound method | 23:45 |
| kmalloc | right. | 23:45 |
| ianw | now it uses "decorate" | 23:45 |
| kmalloc | which means that __get__ is looking at .. i think something else here. | 23:45 |
| kmalloc | yeah, i'm not super familiar with decoratte, that might eat things. | 23:45 |
| ianw | i think the __get__ is right -- that's returning the bound method | 23:46 |
| ianw | e.g. if we're calling self.list_users() | 23:46 |
| ianw | it's the list_users() method of self | 23:46 |
| kmalloc | right. but we're failing when it comes to doing the .set = set_ | 23:46 |
| ianw | then it's essentially calling "cache_on_arguments(self.list_users)" | 23:47 |
| kmalloc | so, with decorate module we might be getting something else back from the __get__ that is resulting on the failure. | 23:47 |
| ianw | well it hasn't got to that point yet | 23:47 |
| ianw | it's assuming it can set "func.set = ... something" | 23:47 |
| kmalloc | the traceback i see is | 23:47 |
| kmalloc | https://www.irccloud.com/pastebin/Dd2zuRog/ | 23:47 |
| ianw | which you can't do on a bound method | 23:47 |
| kmalloc | right. | 23:48 |
| kmalloc | hmm.. i wonder. | 23:48 |
| ianw | ok, we're talking about the same traceback at least :) | 23:48 |
| ianw | splitting it up helps i think | 23:49 |
| ianw | http://paste.openstack.org/ | 23:49 |
| kmalloc | yeah | 23:49 |
| kmalloc | i think i see what is going on | 23:50 |
| ianw | in the old decorator, it would use @wraps(fn) on the incoming user function | 23:50 |
| kmalloc | yes | 23:50 |
| kmalloc | dogpile makes the broad assumption it is doing the wrapping | 23:50 |
| kmalloc | not getting magic instantiated things | 23:51 |
| kmalloc | bound methods. | 23:51 |
| ianw | yes ... probably a fair assumption :) | 23:51 |
| kmalloc | we're probably doing it wrong. | 23:51 |
| ianw | sorry i've got to step out for about 30 minutes for a meeting. i'll be back | 23:52 |
| kmalloc | yeah np. | 23:52 |
| kmalloc | ianw: the solutions are pretty straightforward (cc Shrews, mordred): 1) dogpile reverts, 2) we stop wrapping on-demand, and we lean on something similar to a "should_cache_fn", or always wrap and just lean on the null backend by default, 3) same as 2, but we use should_cache_fn to control if caching is enabled. | 23:54 |
| kmalloc | i think dogpile is probably making the sane assumption it should be allowed to control wrapping. | 23:55 |
| kmalloc | i think we should just always wrap, and let dogpile do that, instead of wrap the bound method. | 23:56 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
