Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-08-15
23:02:05 adriant mordred: ^
23:09:59 openstackgerrit Eric Fried proposed openstack/openstacksdk master: WIP: Connection(strict_proxies) https://review.opendev.org/676837
23:16:36 openstackgerrit Eric Fried proposed openstack/openstacksdk master: WIP: Connection(strict_proxies) https://review.opendev.org/676837
#openstack-sdks - 2019-08-16
02:45:24 openstackgerrit Brin Zhang proposed openstack/python-openstackclient master: Microversion 2.77: Support Specifying AZ to unshelve https://review.opendev.org/665336
11:27:02 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: WIP: Connection(strict_proxies) https://review.opendev.org/676837
11:27:31 mordred efried: I like your version. that ^^ fixes it so that the existing tests work - I'm gonna add new tests now
12:31:35 efried mordred: awesome. I will try to spin up a nova patch that Depends-On it, but I've had trouble making that work recently.
12:32:01 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add strict_proxies option for Connection https://review.opendev.org/676837
12:32:20 mordred efried: that now has tests (that showed some issues, so they're good tests :) )
12:32:36 efried good stuff
12:33:09 mordred efried: I turned on strict_proxies in the from_conf tests - since the overlap of the two is gonna be pretty common
12:33:38 efried mordred: Do you think there's value in getting some real cloud to play around with before we unleash this on the world?
12:33:48 mordred maybe?
12:34:01 efried Since the last couple of iterations have only uncovered more problems we couldn't really have known about
12:34:26 mordred yeah. this is a tricky one
12:34:34 efried The release process is pretty smooth, but still takes a couple of days, so it would be nice to be able to iterate faster.
12:34:44 mordred although isn't it devstack that found the ironic thing?
12:34:53 efried It was devstack CI
12:35:04 mordred yeah - so that's at least good :)
12:35:04 efried which I don't have a way to do, I don't think.
12:35:09 efried I mean locally
12:35:13 efried "locally"
12:36:07 efried Donny at Fortnebula is a teammate, and loves slinging hardware at me, so this is a thing that could be set up in quite short order, and then both of us could play on it.
12:36:23 mordred dtantsur|afk: could use your eyes on https://review.opendev.org/#/c/676837/ - it's related to stuff found between ironic and nova originally
12:36:31 mordred oh cool, donny is awesome
12:36:39 efried indeed
12:47:30 efried mordred: Does _strict_proxies need to be private for some arcane reason related to "Connection objects need to be parsimonious about their public symbols"?
12:48:03 efried Cause as currently used it's accessed through an object, not through `self`, which makes my IDE sad (but is otherwise valid python)
12:50:43 mordred efried: weird that it makes your IDE sad... no, not really - I just tend to make all attributes private unless there's a reason to do otherwise. don't need to stand on principle or anything though
12:51:37 efried not sad like suicidal, just a faint grey underline with hover text like "Accessing a private thing from outside"
13:00:13 mordred oh - because of the instance thing ... private to class and private to library being concepts the ide likely can't just figure out. makes sense at least
13:01:03 efried It can figure them out, it's just a style rule that I have enabled (and personally like anyway)
13:01:16 efried it's totally nbd, I was just curious why you reverted that
13:03:13 mordred we can totally swap it back ... it's also totally nbd here
13:14:45 Shrews ????
13:14:54 Shrews oh, i read that as "ndb", which scared me
13:15:06 Shrews because history
13:15:58 efried at the risk of making a fool of myself... what's ndb?
13:16:36 Shrews a mysql thing mordred and i did stuff worth waaaaaay back in time
13:16:43 Shrews s/worth/with/
13:17:43 Shrews before open source companies sold for billions of $$$
13:20:05 mordred back in the day ...
13:21:14 efried the air is thick with nostalgia
13:21:41 Shrews ooooh, that's what that stench is
13:22:28 mordred I thought it was jus tme
13:25:05 efried all work work work with you, never time for personal hygiene.
15:04:39 cmorpheus mordred: dtantsur|afk thoughts on https://review.opendev.org/676648 ?
15:06:00 efried cmorpheus: Does this not percolate down from https://review.opendev.org/#/c/676648/1/keystoneauth1/adapter.py@150 ?
15:06:33 cmorpheus they don't want to use an adapter for some reason
15:06:34 efried ...or do you need it directly settable on the actual Session (vs the Adapter)?
15:06:35 efried ah
15:06:48 efried there's a few things that are missing in that case.
15:06:59 efried (in general, not related to retries)
15:07:10 efried If you're going to do that, you'll probably also want the other three
15:07:20 efried status code retries, and intervals for both.
15:07:40 mordred yeah. I think they'd be better served by removing all that custom code and using sdk - but I might be biased
15:07:42 efried oh, /me sees the comments now.
15:07:51 cmorpheus mordred: heh
15:07:57 mordred I mean - there's a TON of code in heat/common/context.py
15:08:22 mordred but - maybe there's a reason
15:08:56 mordred honestly, I can't think of a reason to _not_ support adding all of the retry options directly to session - since ultimately it is a session that is the one doing the http layer work and the adapter is an openstack service config layer on top of it
15:09:12 mordred but I agree I think we should add all of them if we're going to add them
15:10:07 mordred but I still think we should start thinking about how we can delete that file from heat
15:10:19 efried mordred: I think it was when I was adding global_request_id (??) that we talked about this and decided it was only necessary to do it on Adapter.
15:11:04 efried oh, actually, I added it to Session.request, never mind.
15:11:23 cmorpheus my general thought was that if you knew you had a flaky service you might want to set retries for that, if all your services are so flaky that you want to set it globally in the session then that is sad times
15:11:52 cmorpheus but i agree i can't think of a really serious reason not to add it to the session
15:12:05 efried cmorpheus: From the comments on that review, and the link into their code, I don't see where they're using a session at all
15:12:24 cmorpheus yeah it is really hard to follow the heat code
15:12:58 efried here https://github.com/openstack/heat/blob/master/heat/common/context.py#L113
15:13:10 efried ...they could wrap that sucker in an Adapter very easily.
15:13:59 mordred yeah. I agree with cmorpheus that it's sad if you have to wrap it for everythig - and with efried that it's hard to see where this would get applied
15:14:19 efried ugh https://github.com/openstack/heat/blob/master/heat/common/config.py#L550 -- they should really be using ks loading
15:14:30 cmorpheus yep :(
15:14:40 efried so
15:14:53 mordred this is just an attempt to nerdsnipe me in to rewriting this code in heat isn' tit?
15:15:05 efried rather than ask ksa to retrofit to support them doing stuff the old way, we should ask them to get with the times
15:15:10 cmorpheus mordred: is it working?
15:15:15 mordred cmorpheus: it's getting close
15:16:37 efried I would say -1 that patch and tell them to do ^ first, unless they can give some really good reason that's not viable.
15:18:28 efried _get_auth_and_session (uses load_{auth|session}_from_conf_options): https://opendev.org/openstack/nova/src/branch/master/nova/utils.py#L1176
15:18:28 efried get_ksa_adapter (uses load_adapter_from_conf_options): https://opendev.org/openstack/nova/src/branch/master/nova/utils.py#L1194
15:18:28 efried If it helps, here's how nova does it:
15:19:21 cmorpheus sweet, thanks for the input guys
15:20:42 efried should be replaced by something more like https://opendev.org/openstack/nova/src/branch/master/nova/conf/utils.py#L58
15:20:42 efried and this stuff https://github.com/openstack/heat/blob/master/heat/common/config.py#L331-L367
15:21:04 efried (ks_loading.register_*_conf_options ^ )
16:07:18 mordred kmalloc: if you get a sec, would you look at https://review.opendev.org/#/c/675187/ and https://review.opendev.org/#/c/675130 - I think you've probably got more context on that than most people
16:10:10 kmalloc looking
16:10:42 kmalloc ooh those ones.. going to take me a few to review it, want to make sure the use is sane.
16:23:45 mordred kmalloc: yes please
18:50:12 kmalloc mordred: phew, this review is making my brain work :)
18:50:22 kmalloc mordred: because i need to keep looking at the fixture :P
18:50:30 kmalloc i *think* your changes are right.
19:06:27 mordred kmalloc: they seem to work at least ...
19:07:06 mordred kmalloc: the goal here is to pull all of the stuff you did with requests-mock into a fixture that provides catalogs and discovery documents and methods to manipulate those things based on the published ksa fixtures
19:07:11 mordred this was step one
19:07:23 mordred kmalloc: but yeah - it's ... right down deep in there
20:02:20 kmalloc yup
21:17:08 kmalloc mordred: added comment to https://review.opendev.org/#/c/675130/, it looks correct but I am confirming an assertion the test is making.

Earlier   Later