| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-01-06 | |||
| 00:32:13 | mordred | johnsom: looking - quick question ... any reason to not just add the octavia config to the other functional jobs? | |
| 00:32:33 | mordred | like - does it increase the memory footprint a bunch and/or is enabling it flaky in any way? | |
| 00:32:50 | johnsom | mordred Run time is the biggest reason we usually don't, but I'm open to it. It was before | |
| 00:33:02 | johnsom | It boots VMs | |
| 00:34:51 | mordred | johnsom: nod. well - I think we can get it going with a second job just to see - that might also make it nicer/easier for octavia to add the sdk functional test to octavia patches | |
| 00:34:56 | johnsom | My thought on this would just push that config down to jobs that need it | |
| 00:35:44 | johnsom | For a base job, it assumes you need a lot of infrastructure (heat, swift, cinder, etc.) | |
| 00:36:06 | mordred | yah - well, so far those have been fairly standard - but I agree, I think we can restructure that a bit more | |
| 00:36:55 | johnsom | Ok, so should I take that on tomorrow or just setup a separate octavia job replicating that parts of that I care about? | |
| 00:39:31 | mordred | johnsom: I think refactoring that base job sounds like a good idea if you're up for it - we should probably add an OPENSTACKSDK_HAS_CINDER var and an entry https://review.openstack.org/#/c/531514/1/openstack/tests/functional/cloud/test_devstack.py like you did for octavia | |
| 00:39:59 | mordred | johnsom: since this'll be the first time we'll have jobs that don't have a cinder - making sure we don't accidentally fail open at some point == good | |
| 00:40:31 | johnsom | mordred Ok, I will look into that all tomorrow | |
| 00:40:42 | mordred | thanks! I think this'll be a nice improvement | |
| 00:41:26 | mordred | johnsom: fwiw, this took me down a rabbit hole of realizing that heat uses openstacksdk, that I need to make them a patch like I made you, and then all the way down the hole when I realized I could make the heat patch better by refactoring something in sdk | |
| 00:42:22 | johnsom | lol, sorry/not sorry | |
| 00:42:51 | mordred | hehe. it happens :) | |
| 00:43:09 | mordred | I'm just looking forward to assaulting dtroyer and Shrews with the results | |
| 09:07:46 | openstackgerrit | Rabi Mishra proposed openstack/osc-lib master: Fix find() interface when attr is not specified https://review.openstack.org/529934 | |
| #openstack-sdks - 2018-01-07 | |||
| 00:12:50 | openstackgerrit | Michael Johnson proposed openstack/python-openstacksdk master: Add an octavia functional test gate https://review.openstack.org/531514 | |
| 17:00:06 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Update for new docs PTI https://review.openstack.org/530978 | |
| 17:00:07 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Remove name from zuul project stanza https://review.openstack.org/531267 | |
| 17:00:07 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Port wait_for_ methods to use iterate_timeout https://review.openstack.org/531268 | |
| 17:00:08 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Prefer links dicts for pagination https://review.openstack.org/530769 | |
| 17:00:08 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Use sdk for list_servers https://review.openstack.org/530770 | |
| 17:00:09 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: WIP Make resource a dict subclass usable by shade layer https://review.openstack.org/530835 | |
| 17:00:09 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Rename CloudConfig to CloudRegion https://review.openstack.org/531611 | |
| 17:00:10 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Add function to make CloudRegion from session https://review.openstack.org/531612 | |
| 20:56:11 | openstackgerrit | Michael Johnson proposed openstack/python-openstacksdk master: Add an octavia functional test gate https://review.openstack.org/531514 | |
| 22:06:36 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Rename CloudConfig to CloudRegion https://review.openstack.org/531611 | |
| #openstack-sdks - 2018-01-08 | |||
| 01:44:47 | openstackgerrit | Michael Johnson proposed openstack/python-openstacksdk master: Add an octavia functional test gate https://review.openstack.org/531514 | |
| 02:43:04 | openstackgerrit | Bar Elharar proposed openstack/osc-lib master: Suppress subTest() expected errors https://review.openstack.org/531025 | |
| 02:56:22 | openstackgerrit | Bar Elharar proposed openstack/osc-lib master: Suppress subTest() expected errors https://review.openstack.org/531025 | |
| 06:20:41 | openstackgerrit | Merged openstack/python-openstacksdk master: Updated from global requirements https://review.openstack.org/525689 | |
| 14:25:46 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Rename CloudConfig to CloudRegion https://review.openstack.org/531611 | |
| 14:26:30 | mordred | Shrews: if you have a sec, https://review.openstack.org/#/c/530978 and https://review.openstack.org/#/c/531267 are both super simple/mechanical | |
| 14:28:13 | Shrews | mordred: YOU'RE super simple/mechanical | |
| 15:28:22 | openstackgerrit | Merged openstack/python-openstacksdk master: Update for new docs PTI https://review.openstack.org/530978 | |
| 15:45:36 | openstackgerrit | Merged openstack/python-openstacksdk master: Remove name from zuul project stanza https://review.openstack.org/531267 | |
| 17:04:02 | mordred | briancurtin: responded to your note on the dict patch - thanks for the background! I've got one more thing to try, will ping you when its up- might be tomorrow | |
| 17:04:24 | mordred | briancurtin: however, it's also entirely possible the results here will be "unpossible/bad idea" | |
| 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 | |