Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-06-19
08:57:05 openstackgerrit Surya Seetharaman proposed openstack/python-openstackclient master: Microversion 2.73: Support adding the reason behind a server lock https://review.opendev.org/659124
09:03:53 openstackgerrit yanpuqing proposed openstack/python-openstackclient master: Client should parse string to boolean for value 'is_domain' https://review.opendev.org/665629
09:06:34 openstackgerrit yanpuqing proposed openstack/python-openstackclient master: Client should parse string to boolean for value 'is_domain' https://review.opendev.org/665629
09:09:04 openstackgerrit yanpuqing proposed openstack/python-openstackclient master: Client should parse string to boolean for value 'is_domain' https://review.opendev.org/665629
09:12:42 openstackgerrit yanpuqing proposed openstack/python-openstackclient master: Client should parse string to boolean for value 'is_domain' https://review.opendev.org/665629
12:33:43 dtantsur mordred: morning! do I get it right that loading a Connection from an oslo config doesn't allow to set various SDK-specific options, such as retry count?
12:35:59 mordred dtantsur: yeah - I think we don't have support for that. there was discussion about adding support to the oslo.config loading to allow specifying a named cloud profile and then having things get loaded from a clouds.yaml (so that the oslo.config section would ultimately just be a pointer to the clouds.yaml) - but that hasn't been fully specced out yet
12:36:36 dtantsur I see. It makes it harder to switch to this feature (and I wonder what Nova folks are going to do about options, such as retry count. efried?)
12:37:24 mordred we could also potentially add support for specifying them I imagine
12:39:51 dtantsur coffee++
12:44:47 efried dtantsur: "switch to this feature" -- you mean retrofit something that currently uses clouds.yaml to using oslo.config instead? Or you mean switching something like nova over from its current oslo.config-to-load-ksa to oslo.config-to-load-sdk?
12:45:23 dtantsur efried: the latter. e.g. making https://github.com/openstack/nova/blob/master/nova/conf/ironic.py#L41 still work
12:46:26 efried dtantsur: oic. Are these options normally available in clouds.yaml?
12:47:47 dtantsur efried: this one is implemented under a different name (something like status_code_retries)
12:48:08 dtantsur https://github.com/openstack/nova/blob/master/nova/conf/ironic.py#L54 is not implemented (retries are exponential)
12:48:48 efried so let me ask you this dtantsur: is it actually important that these values continue to be configurable?
12:51:03 efried dtantsur: If the options are available to the Connection() constructor, it would be pretty easy to plumb a **kwargs through here: https://review.opendev.org/#/c/643664/20/nova/utils.py@1252
12:51:37 dtantsur efried: the api_retries is an important one for ironic, yes. I know that at least tripleo raises it quite significantly.
12:51:55 dtantsur I don't remember if adapter options are available in Connection. mordred?
12:53:12 efried get_cloud_region...
12:54:05 efried nope
12:57:49 efried dtantsur: Okay, I can see a way to make this work, at least for status_code_retries, if there's not something else in place.
12:59:24 efried but, ugh, for the ones that aren't supported (like the retry interval), we might have to maintain both code paths in nova, deprecate the option, and remove the old code path and the option at the same time in a future release.
13:00:06 efried dtantsur, dustinc: How immediate is the need for this? Do you want me to sling something together today?
13:02:00 dtantsur efried: I'm looking into updating keystoneauth actually
13:03:19 efried dtantsur: Oh, is this an option that was added to the ksa.Adapter constructor but not to its config opts?
13:05:09 dtantsur yep
13:05:19 mordred ah - yeah - that would be a better fix probably
13:05:31 mordred also - oops
13:05:32 efried okay, yeah, for sure.
13:05:34 dtantsur and there is a sanity fix required there, hold on
13:10:35 openstackgerrit Dmitry Tantsur proposed openstack/keystoneauth master: Limit interval between retries to 1 minute https://review.opendev.org/666284
13:10:37 dtantsur I know tripleo loves enormous retries, so ^^^
13:24:58 openstackgerrit Dmitry Tantsur proposed openstack/keystoneauth master: Allow setting retry counts for Adapter via configuration options https://review.opendev.org/666287
13:25:00 dtantsur efried, mordred ^^^
13:27:03 dtantsur now I wonder if we need an option for retry interval
13:27:17 dtantsur I definitely don't want to maintain two code paths..
13:27:48 mordred dtantsur: -1 on the limit with what would normally be a nit but in this case I think is salient
13:28:57 openstackgerrit Dmitry Tantsur proposed openstack/keystoneauth master: Limit interval between retries to 1 minute https://review.opendev.org/666284
13:28:58 dtantsur oh FFS when will I stop confusing these words??
13:29:06 dtantsur thanks mordred, updated!
13:30:45 mordred dtantsur: they're more easily distinguishable in german :)
13:31:18 dtantsur definitely! I'm confusing other words here :D
13:32:28 dtantsur I cannot make up my mind on whether we should support setting retry intervals (overriding exponential retries)
13:36:43 efried dtantsur: I'm a proponent of "fewer knobs" wherever possible. I can't imagine a configurable retry interval is really important to anyone (whether they think it is or not).
13:47:40 dtantsur efried: I'm only concerned with upgrades. E.g. if something like tripleo has set api_retries=20 retry_interval=2 (40 seconds totally), which now will turn into many minutes.
13:51:43 dtantsur otherwise "fewer knobs"++
14:00:01 efried Are there really scenarios in tripleo where there are more than a couple of retries?
14:00:27 efried I guess if we're a deployment tool and we're waiting for a service to come up, having a fixed rather than exponential retry makes sense...
14:00:49 efried so, sigh, yeah, I guess it still makes sense for it to be configurable.
14:09:01 dtantsur efried: crazy hardware where BMC can start thinking for a minute about a power on request, locking a node in ironic?
14:09:16 dtantsur it happens less and less frequently, but still happens
14:25:02 dtantsur mordred: when you have a minute: https://review.opendev.org/#/c/665645/
14:27:08 mordred dtantsur: I really want a string subclass that is case-insensitive and treats - and _ the same
14:27:17 mordred dtantsur: I feel like it would make so many things easier
14:27:20 dtantsur totally
14:27:39 mordred I'll write one in all of my copious free time
14:28:15 dtantsur in your WHAT
14:28:29 mordred I mean - actually - requests already has a caseinsensitive dict it uses for headers- we could totally start using it for our internal dicts
14:29:00 mordred and maybe even update oslo.config to do the same (or similar) so that "foo-bar" in config_object would work as seamlessly as it does with response.headers
14:29:11 mordred but - yeah - still too much work for now
14:29:26 mordred +A on that patch
14:47:29 dtantsur thx!
15:16:57 dtantsur is keystoneauth CI broken?
15:17:05 dtantsur the pep8 job tries to run bandit for some reason (and fails)
15:57:09 openstackgerrit Merged openstack/openstacksdk master: from_conf: fix handling service names with dashes https://review.opendev.org/665645
16:14:32 openstackgerrit jacky06 proposed openstack/os-client-config master: Sync Sphinx requirement https://review.opendev.org/666379
16:29:53 openstackgerrit jacky06 proposed openstack/os-service-types master: Sync Sphinx requirement https://review.opendev.org/666384
16:30:37 mordred dtantsur: uh.
16:30:51 mordred cmurphy, kmalloc: ^^ I thought I saw something about bandit a while back or something?
16:31:27 cmurphy um
16:33:04 kmalloc uh
16:33:20 kmalloc bandit was broken for lots of things.
16:33:27 kmalloc but afaik that was fixed
16:33:49 cmurphy did it release again?
16:34:24 cmurphy yep on friday
16:35:15 mordred http://logs.openstack.org/84/666284/2/check/openstack-tox-pep8/77e2cf5/job-output.txt.gz seems unhappy with access_token_type='access_token' in the oidc driver
16:35:21 kmalloc and it totally mis-catches that as a password
16:35:24 mordred yeah
16:35:26 kmalloc yeah... nope.
16:35:35 kmalloc i am less and less impressed with the bandit development
16:36:11 kmalloc i am guessing it's doing a crappy match on the word 'password' in the function signature
16:36:16 kmalloc as a kwarg.
16:36:20 openstackgerrit Colleen Murphy proposed openstack/keystoneauth master: Cap bandit https://review.opendev.org/666388
16:37:20 kmalloc cmurphy: +2/+A fast land if it passes zuul.
16:37:44 kmalloc cmurphy: feel free to self-approve if subsequent minor changes are needed (Carry my +2/+A) for unbreaking the KSA gate.
16:37:58 cmurphy kmalloc: o7
16:39:23 kmalloc :P
16:48:53 dtantsur my API SIG friends, elmiko and edleafe (and everybody who cares): I'll be likely out for the next 2.5 weeks (i.e. 3 Thursdays)
16:49:23 gtema dtantsur: eh, lucky
16:49:40 dtantsur gtema: one week of that is a f2f meeting :)
16:49:55 dtantsur and on Friday I'm out because of the German exam, brrrr
16:50:02 dtantsur so my luck is only for the last week :)
16:50:03 gtema hehehe
16:50:20 gtema good luck with exam
16:50:31 dtantsur thank you, I feel like I'll need it :)
16:50:53 gtema Du muss es schaffen
16:52:51 mordred He must sheep it?
16:53:48 gtema nope - 2 "f" - means - do it (accomplish)
16:53:58 dtantsur :D

Earlier   Later