Posted	Nick	Remark
#openstack-sdks - 2019-06-19
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
16:54:03	gtema	and 1 "f" is a sheep
16:54:28	dtantsur	ich hoffe, das ich es nicht schafen werde :D
16:54:52	gtema	wieso nur??
16:54:58	mordred	ahhh
16:55:56	dtantsur	ich wäre nicht ein Schaf :D
16:56:12	dtantsur	anyway, enough of my silly German, see you later
16:56:25	mordred	ich esse Schafen gern
16:56:34	gtema	ich auch
16:56:55	dtantsur|afk	\o
16:57:03	edleafe	dtantsur|afk: enjoy!
17:08:16	elmiko	dtantsur|afk: ack, thanks for the heads up. have fun =)

Earlier   Later