| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-12-13 | |||
| 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 | dtantsur | SOAP never greaks contracts, it's enterprise-grade | |
| 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: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 | 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: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: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 | dtantsur | if we were less hipster, we would just use "API version" | |
| 16:48:06 | edleafe | or, you know, "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 | |
| 16:54:20 | edleafe | We could just follow git's lead and make the version a hash of the codebase | |
| 16:55:02 | elmiko | edleafe: haha, <3 random integers | |
| 16:55:05 | dtantsur | nice! it will add a pleasant task of figuring out how to put a hash in the file being hashed | |
| 16:55:31 | 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:31 | dtantsur | or we could get boring and use the current date and time | |
| 16:55:38 | elmiko | *middleware | |
| 16:55:53 | edleafe | dtantsur: no problem. Internally you do a 'git checkout {hash}' and then run the request through that | |
| 16:56:01 | elmiko | hahaha | |
| 16:56:17 | edleafe | simple! | |
| 16:56:49 | elmiko | really randoversioning is an upgrade, because it helps project maintainers know who is _really_ following the project | |
| 16:57:40 | elmiko | "i'm using the latest, version 3831923", "ah ah, didn't you know the latest is actually 92359841?!?" | |
| 16:57:49 | elmiko | busted! | |
| 16:58:43 | edleafe | So not only could we replace 'latest' with 'HEAD', we now have access to 'HEAD^', 'HEAD^^', etc | |
| 16:58:46 | dtantsur | folks, you keep forgetting that in year 2018 we *must* be mobile-friendly | |
| 16:58:58 | dtantsur | so I recommend we start using smiles in versions | |
| 16:59:15 | dtantsur | * smileys | |
| 16:59:44 | edleafe | Better yet: animojis! | |
| 17:00:11 | elmiko | haha, perfect | |
| 17:00:12 | edleafe | https://emojipedia-us.s3.amazonaws.com/content/2017/09/21/animoji-poo-emojipedia.gif | |
| 17:00:33 | elmiko | dtantsur: micromoji-versioning? | |
| 17:00:42 | edleafe | I guess our office hour is up. | |
| 17:00:46 | elmiko | ah well | |