| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-12-13 | |||
| 16:28:58 | cdent | the URI is the primary thing | |
| 16:29:01 | kmalloc | XXX is checked before XXXX/YYYY | |
| 16:29:05 | kmalloc | so, XXX hits 404 | |
| 16:29:09 | kmalloc | sure. | |
| 16:29:10 | cdent | if there is _nothing_ that has that URI, then 404 | |
| 16:29:19 | cdent | if you can GET it, but can't delete it, then 405 | |
| 16:29:54 | kmalloc | but a 404 on a delete where a resource could exist is explictly wrong | |
| 16:30:00 | kmalloc | it's always a success if delete could work | |
| 16:30:10 | kmalloc | cdent: ++ don't have to convince me too hard on that front :P | |
| 16:30:14 | cdent | that's effectively what ed's thing say | |
| 16:30:25 | edleafe | kmalloc: that's what the point of https://review.openstack.org/#/c/616610/ is | |
| 16:30:31 | edleafe | jinx | |
| 16:30:34 | kmalloc | hehe | |
| 16:30:40 | 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:48 | kmalloc | yep. | |
| 16:30:51 | cdent | but if the url is invalid because you can't even GET there, then 404 | |
| 16:30:56 | cdent | s/even/ever/ | |
| 16:30:58 | kmalloc | yes. | |
| 16:31:07 | kmalloc | i could see that, i'll have to go poke and see how flask handles it | |
| 16:31:13 | kmalloc | i think it does it the correct way | |
| 16:31:20 | kmalloc | what you just described | |
| 16:31:31 | kmalloc | because if not, i have some bugs to go open/fix | |
| 16:31:38 | elmiko | edleafe: fwiw, i'm still +1 on the review | |
| 16:31:51 | elmiko | lol | |
| 16:31:59 | elmiko | seems like dtantsur will be the -1 | |
| 16:32:03 | dtantsur | yep | |
| 16:32:28 | edleafe | One thing to keep in mind before you -1: | |
| 16:32:45 | edleafe | This is a guideline; it says what projects should ideally follow | |
| 16:33:11 | edleafe | We are trying to encourage new projects to follow them. Existing projects do not have to change | |
| 16:34:08 | 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:17 | kmalloc | we just have a ton of history that... well we can't "just fix" | |
| 16:34:29 | edleafe | kmalloc: sure, that's reasonable. | |
| 16:34:31 | elmiko | kmalloc: totally understandable | |
| 16:34:54 | elmiko | to echo edleafe, these are guidelines and not laws | |
| 16:34:59 | kmalloc | also we don't have (and doesn't look like we will in the near-to-medium term) microversions :) | |
| 16:35:08 | kmalloc | also +1 on that change. I like the guidelines | |
| 16:35:19 | 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:22 | elmiko | imo, microversions seem less contentious. but i'm just one person | |
| 16:35:33 | edleafe | elmiko: lol | |
| 16:35:34 | elmiko | edleafe ++ | |
| 16:35:36 | kmalloc | i'd like to really outline the use of 405 in that doc. | |
| 16:35:41 | kmalloc | because it is useful. | |
| 16:35:52 | kmalloc | but that is a bigger bundle of "lots of comments" | |
| 16:35:57 | dtantsur | microversions are not contentious at all, just do them | |
| 16:36:05 | elmiko | dtantsur: LOL | |
| 16:36:14 | kmalloc | dtantsur: ok, go implement it for keystone, i think you just volunteered :) :P :P :P | |
| 16:36:20 | edleafe | kmalloc: http://specs.openstack.org/openstack/api-sig/guidelines/http/response-codes.html#failure-code-clarifications | |
| 16:36:35 | dtantsur | how many years it took us to implement proper negotiation in OSC? oh wait, it's still not there? :) | |
| 16:36:43 | edleafe | There is a paragraph there on 405 | |
| 16:36:50 | kmalloc | edleafe: yes, but i think that needs some expansion | |
| 16:37:05 | edleafe | patches welcome! :) | |
| 16:37:11 | kmalloc | yes, it's on my long long long list | |
| 16:37:14 | kmalloc | :) | |
| 16:37:21 | dtantsur | kmalloc: I'll switch keystone to SOAP | |
| 16:37:36 | kmalloc | dtantsur: if you can get people to approve it... and not break our API contracts, go for it | |
| 16:37:44 | kmalloc | dtantsur: i'll even volunteer to not -2 that change | |
| 16:37:50 | kmalloc | or even -1 it. | |
| 16:37:52 | 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:52 | dtantsur | SOAP never greaks contracts, it's enterprise-grade | |
| 16:38:19 | dtantsur | edleafe: /me imagines $ curl https://baremetal.example.com/v56/nodes | |
| 16:38:56 | dtantsur | it's mostly kidding again, but I do feel bad that we break RESTfulness with microversions | |
| 16:40:06 | dtantsur | hehe | |
| 16:40:18 | elmiko | but then i am a smelly hippy, so there is that XD | |
| 16:40:23 | dtantsur | I got some funny experience with it | |
| 16:40:41 | elmiko | if you had "fun" anywhere near SOAP then you are doing better than most ;) | |
| 16:40:45 | 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:53 | elmiko | ouch | |
| 16:40:54 | dtantsur | they had different SOAPs apparently | |
| 16:40:59 | elmiko | LOL | |
| 16:41:28 | edleafe | I made a python SOAP server talk with a .NET client | |
| 16:41:57 | dtantsur | nice! | |
| 16:42:34 | 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:41 | 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:43:25 | 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:25 | 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:36 | dtantsur | :) | |
| 16:43:56 | dtantsur | e.g. I cannot say /v1/portgroups/<UUID> is a representation of a portgroup <UUID> | |
| 16:44:11 | dtantsur | because it's only the case if microversion>=1.<something> | |
| 16:44:59 | elmiko | edleafe: heh, xml actually /solving/ problems... XD | |
| 16:45:03 | dtantsur | this defeats e.g. the "Location" header to a degree, since "Location" is meaningless without a microversion to use it with | |
| 16:45:28 | 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:46:24 | cdent | dtantsur: yeah, I feel really bad about URIs that exist in microversion N+1 but not N. It's dirty. | |
| 16:46:59 | 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:47:03 | 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:14 | cdent | until placement, yo | |
| 16:47:38 | edleafe | cdent: that's why I really hate the term "microversion". It's anything but micro | |
| 16:47:51 | cdent | really-hugeo-version | |
| 16:47:59 | edleafe | megaversion | |
| 16:48:06 | edleafe | or, you know, "version" | |
| 16:48:06 | dtantsur | if we were less hipster, we would just use "API version" | |
| 16:48:11 | dtantsur | ha! | |
| 16:48:47 | elmiko | cdent: lol | |
| 16:48:56 | edleafe | the only difference with microversions is that we simultaneously support many, many possible versions | |
| 16:49:49 | elmiko | i like "really-hugeo-version", it has a nice ring to it. would make debates much more lively | |
| 16:50:20 | elmiko | but, i am a fan of absurdism | |
| 16:51:31 | dtantsur | then we also have to be creative with numbers themselves | |
| 16:52:28 | elmiko | ooh, nice | |
| 16:53:01 | edleafe | we should use random integers for our versions. | |
| 16:53:28 | 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:57 | edleafe | dtantsur: too much work | |