| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-01-08 | |||
| 17:48:29 | briancurtin | mordred: ok cool, sounds good | |
| 17:49:23 | mordred | edleafe, elmiko: was just chatting with notmyname verifying that I was understanding swift pagingation correctly | |
| 17:50:00 | mordred | edleafe, elmiko: and in doing so I discovered that requests parses rfc5988 headers automatically: http://docs.python-requests.org/en/master/user/advanced/#link-headers | |
| 17:50:41 | mordred | edleafe, elmiko: given the variation in how pagination links are returned today, and how unlikely it is that we'd be able to get all the services aligned on one approach - since backwards compat would make it living hell ... | |
| 17:51:19 | mordred | what if we changed the recommendation to start publishing rfc5988 compliant links headers - the data is the same as what peopel are already putting in links bodies (slightly different format, but whatever) | |
| 17:53:18 | mordred | since it's a standard header that's intended to be used for that, it shouldn't be a backwards compat issue - and clients could easily consume Links headers if they exist, and otherwise fallback to existing "look for resp.json()['links'] or resp.json['{resource}_links'] or resp.json()['next'] or an object count in resp.headers" | |
| 17:55:25 | edleafe | mordred: so if I understand you correctly, projects could leave their assorted formats in the response body alone, and just add the necessary headers? | |
| 17:55:53 | edleafe | mordred: and then clients could just check for the next/prev link from the headers? | |
| 18:27:12 | elmiko | mordred: assuming what edleafe says is accurate, that makes entirely too much sense ;) | |
| 18:37:52 | mordred | elmiko, edleafe: yes! | |
| 18:38:00 | mordred | cdent: also ... ^^ | |
| 18:38:19 | cdent | mordred: yeah, was just reading through that | |
| 18:38:29 | mordred | cdent: http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2018-01-08.log.html#t2018-01-08T17:49:23 | |
| 18:38:31 | mordred | oh - good | |
| 18:39:38 | cdent | I've never been a huge fan of link headers, but it does provide a nice solution in this case | |
| 18:39:58 | mordred | in an uncommon fit of things being nice - it's an update that would work for swift as well (GET on a container just returns a list in swift, it does not return a top-level dict, so there is no entity to which a links entity could be added) | |
| 18:40:09 | cdent | mostly because it means the representation needs to carry around the headers with itself to be "complete" | |
| 18:40:14 | elmiko | i don't have a strong opinion about using the headers, but agree this could be a really nice way to solve the issue for consistency's sake | |
| 18:40:32 | elmiko | mordred: ooh a unicorn! | |
| 18:40:34 | mordred | cdent: yah | |
| 18:41:01 | elmiko | cdent: ah, good point, i hadn't considered that angle | |
| 18:41:22 | mordred | it should also be REALLY easy for people to implement, I'd think - anyone who has a links dict already has the hard bits done, just encoding it and ading it to the headers should be like an afternoon task for an intern | |
| 18:41:47 | cdent | i don't think it being headers is a blocker, just violates my picky aesthetics | |
| 18:41:49 | edleafe | cdent: not sure I agree. If the representation is complete now, adding a header will just add a redundancy for compatibility across projects | |
| 18:42:05 | cdent | frequently the representation is not complete | |
| 18:42:20 | cdent | or at least not consistent, which is how we ended up looking for a different solution | |
| 18:42:24 | edleafe | cdent: sure, but how does adding a header change that? | |
| 18:42:40 | edleafe | ah, the consistent part is the holy grail | |
| 18:42:49 | cdent | it means we aren't "forcing" the representations to cohere | |
| 18:42:56 | mordred | aren't pagination links temporal in nature anyway? or were you thinking about it in the more general case of links headers for things like a 'server' | |
| 18:42:57 | edleafe | cdent: we can't | |
| 18:43:13 | cdent | thus the quotes | |
| 18:43:20 | cdent | like I said, I'm okay with it. | |
| 18:43:56 | edleafe | OK, new APIs: follow our guides. Existing, non-conformant APIs: add the headers | |
| 18:44:10 | elmiko | seems like pagination in specific is in a little bit of a grey area for the headers/representation issue | |
| 18:44:11 | edleafe | I'm not sure where you see the problem | |
| 18:44:18 | cdent | mordred: I was thinking about the representation passing through various code boundaries, but still being the "now" representation | |
| 18:44:47 | cdent | edleafe: what I just said to mordred: if next is only the headers and not in the json, when it passes from library X to thing Y... | |
| 18:44:57 | cdent | which maybe is not something we care about | |
| 18:45:36 | cdent | and is certainly not something worth stopping this good idea over | |
| 18:45:51 | cdent | (merely something to be aware of) | |
| 18:46:33 | edleafe | cdent: if it's not in the json, then a project has a choice: change the API, or add a header | |
| 18:46:48 | edleafe | the header thing is a workaround only | |
| 18:47:28 | cdent | right, and if they add the header, then when the client gets a representation the body will, in a sense, be incomplete after it passes away from the part of the system paying attention to headers | |
| 18:47:32 | cdent | which may not matter | |
| 18:48:02 | mordred | yah - I mean, the header is a nice thing to add since it's a known thing and even already parsed by things like requests - and is usable for corner cases like listing the objects in a swift container | |
| 18:48:30 | mordred | but having the links in the json body for new apis is the recommendation for well formed json | |
| 18:48:42 | edleafe | I guess I'm understanding it in reverse. Client checks the body and either a) there are no links or b) the links do not follow the standard. Then, as a last resort, it checks the headers | |
| 18:49:50 | cdent | I gotta go, will check the logs for more, if it happens, but overall, seems a good thing. | |
| 18:50:03 | mordred | oh - I was thinking look for the headers first, since it's an rfc 'standard' thing, and if there are no links there, then look for content in body - at least for things like following pagination | |
| 18:50:05 | mordred | BUT | |
| 18:50:24 | mordred | for the love of all that is holy, we should DEFINITELY not be ok with the links headers and links in the body being out of sync | |
| 18:50:38 | mordred | so a client could also totally implement it in either direction and be accurate | |
| 18:50:58 | edleafe | mordred: from an API-SIG POV, we want to encourage projects to form pagination links correctly in the body | |
| 18:51:03 | mordred | yah | |
| 18:51:07 | elmiko | +1 | |
| 18:51:08 | mordred | I tihnk we always want links in the body | |
| 18:51:34 | elmiko | the dual header/body issue seems like it could be a total pita if someone try to implement both or gets caught between the two | |
| 18:51:48 | edleafe | if they are there but in the wrong format, they should update it to be correct, but that requires an API break (or microversion) | |
| 18:51:58 | elmiko | but, i like the idea of recommending the rfc for older projects to gain some sort of consistency | |
| 18:52:27 | edleafe | elmiko: yeah, which is why I saw things happening in the order I mentioned | |
| 18:52:42 | elmiko | plus, it seems to me that header addition can be done on minor version bump, so it doesn't need to upset the whole apple cart. is that an accurate asessment? | |
| 18:52:52 | elmiko | edleafe: ack | |
| 18:52:53 | mordred | I don't think the header addition needs a version bump | |
| 18:53:17 | elmiko | well, it should carry a minor version bump to denote the change though, shouldn't it? | |
| 18:53:21 | mordred | there is NO WAY clients are consuming headers strictly | |
| 18:53:42 | mordred | no - because clients have to account for proxies/api gateways/whatever in between | |
| 18:53:56 | mordred | so there's always the possibilities of more keys being in the header tahn theAPI says will be there | |
| 18:54:07 | elmiko | true that | |
| 18:55:29 | mordred | so, I mean, people could bump a min, but I don't think it would be valuable to anyone - nor do I think doing a microversion dance to know if you can request a microversion that adds links headers would benefit anyone, since the consumption is "if 'links' in response.headers:" | |
| 18:56:10 | elmiko | that makes sense | |
| 18:56:41 | elmiko | i guess, i tend to think about bumping the version to represent changes. but i think you're absolutely correct about not needing to do the "dance" for this type of feature | |
| 19:34:33 | openstackgerrit | Michael Johnson proposed openstack/python-openstacksdk master: Add an octavia functional test gate https://review.openstack.org/531514 | |
| 19:35:34 | openstackgerrit | Michael Johnson proposed openstack/python-openstacksdk master: Add an octavia functional test gate https://review.openstack.org/531514 | |
| 19:37:29 | openstackgerrit | Michael Johnson proposed openstack/python-openstacksdk master: Add an octavia functional test gate https://review.openstack.org/531514 | |
| 21:38:29 | mordred | elmiko, edleafe: the existing guideline actually already references rfc5988 | |
| 21:44:58 | edleafe | mordred: well, waddya know - guess I should have reviewed that before discussion :) | |
| 21:46:02 | edleafe | So no change to the guideline is needed for this. Easy! | |
| 21:46:13 | edleafe | cdent: elmiko: ^^^ | |
| 21:46:50 | mordred | edleafe: :) | |
| 21:47:11 | mordred | edleafe: I'm adding a little text and a sub-heading so that it's easy to deep-link to real quick | |
| 21:51:14 | elmiko | mordred: sweet! thanks for doing all the leg work =) | |
| 21:52:56 | edleafe | mordred: yeah, what elmiko said. I'm heads down in other stuff right now | |
| 21:53:03 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: Expand note about rfc5988 link header https://review.openstack.org/531914 | |
| 22:30:26 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Add function to make CloudRegion from session https://review.openstack.org/531612 | |
| 22:30:26 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Port wait_for_ methods to use iterate_timeout https://review.openstack.org/531268 | |
| 22:30:27 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Prefer links dicts for pagination https://review.openstack.org/530769 | |
| 22:36:03 | openstackgerrit | Michael Johnson proposed openstack/python-openstacksdk master: Add an octavia functional test gate https://review.openstack.org/531514 | |
| 22:46:51 | openstackgerrit | Monty Taylor proposed openstack-infra/shade master: List ansible/ansible in required-projects https://review.openstack.org/531919 | |
| 23:05:18 | openstackgerrit | Michael Johnson proposed openstack/python-openstacksdk master: Add an octavia functional test gate https://review.openstack.org/531514 | |
| #openstack-sdks - 2018-01-09 | |||
| 00:03:51 | openstackgerrit | Monty Taylor proposed openstack-infra/shade master: List ansible/ansible in required-projects https://review.openstack.org/531919 | |
| 00:06:37 | openstackgerrit | Monty Taylor proposed openstack-infra/shade master: List ansible/ansible in required-projects https://review.openstack.org/531919 | |
| 00:24:40 | openstackgerrit | Monty Taylor proposed openstack-infra/shade master: List ansible/ansible in required-projects https://review.openstack.org/531919 | |
| 00:48:18 | openstackgerrit | Michael Johnson proposed openstack/python-openstacksdk master: Add an octavia functional test gate https://review.openstack.org/531514 | |
| 02:36:13 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-openstacksdk master: Updated from global requirements https://review.openstack.org/531974 | |
| 04:45:58 | openstackgerrit | Michael Johnson proposed openstack/python-openstacksdk master: Add an octavia functional test gate https://review.openstack.org/531514 | |
| 06:35:06 | chenyb4 | briancurtin, Hi, I have a question, "openstack.config.exceptions.OpenStackConfigException: Cloud defaults was not found." why not? | |
| 09:13:57 | openstackgerrit | lei zhang proposed openstack/python-openstackclient master: Fix the incorrect git.openstack.org source URL https://review.openstack.org/532108 | |
| 12:47:02 | briancurtin | chenyb4: no idea. what did you do? | |
| 16:12:44 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Add function to make CloudRegion from session https://review.openstack.org/531612 | |