Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-06-14
17:20:04 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Volume.Backup restore fixes https://review.opendev.org/665110
19:16:13 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Volume.Backup restore fixes https://review.opendev.org/665110
19:27:05 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Switch cloud layer to use proxy for DNS https://review.opendev.org/665435
19:29:41 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Switch cloud layer to use proxy for DNS https://review.opendev.org/665435
#openstack-sdks - 2019-06-17
09:16:30 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Volume.Backup restore fixes https://review.opendev.org/665110
09:44:21 openstackgerrit yanpuqing proposed openstack/python-openstackclient master: [WIP]Client should parse string to boolean for valuse 'is_domain' https://review.opendev.org/665629
09:53:09 openstackgerrit yanpuqing proposed openstack/python-openstackclient master: [WIP]Client should parse string to boolean for value 'is_domain' https://review.opendev.org/665629
10:30:41 dtantsur folks, will https://github.com/openstack/openstacksdk/commit/86ad9debd1cb08c2a2e53fd30502b020a0c3e4fe work if a project name contains dashes? I suspect no
10:45:38 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Switch cloud layer to use proxy for DNS https://review.opendev.org/665435
11:20:49 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: from_conf: fix handling service names with dashes https://review.opendev.org/665645
11:20:50 dtantsur and here goes the fix ^^^
11:40:40 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Volume.Backup restore fixes https://review.opendev.org/665110
12:10:56 openstackgerrit yanpuqing proposed openstack/python-openstackclient master: [WIP]Client should parse string to boolean for value 'is_domain' https://review.opendev.org/665629
12:54:00 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Switch cloud layer to use proxy for DNS https://review.opendev.org/665435
17:31:32 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Switch cloud layer to use proxy for DNS https://review.opendev.org/665435
17:33:42 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Switch cloud layer to use proxy for DNS https://review.opendev.org/665435
#openstack-sdks - 2019-06-18
01:42:32 openstackgerrit yanpuqing proposed openstack/python-openstackclient master: [WIP]Client should parse string to boolean for value 'is_domain' https://review.opendev.org/665629
04:03:24 openstackgerrit yanpuqing proposed openstack/python-openstackclient master: [WIP]Client should parse string to boolean for value 'is_domain' https://review.opendev.org/665629
06:49:24 openstackgerrit yanpuqing proposed openstack/python-openstackclient master: [WIP]Client should parse string to boolean for value 'is_domain' https://review.opendev.org/665629
07:30:14 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Switch cloud layer to use proxy for DNS https://review.opendev.org/665435
07:50:41 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Volume.Backup restore fixes https://review.opendev.org/665110
11:39:26 openstackgerrit yanpuqing proposed openstack/python-openstackclient master: [WIP]Client should parse string to boolean for value 'is_domain' https://review.opendev.org/665629
14:54:20 openstackgerrit jacky06 proposed openstack/cliff master: Sync Sphinx requirement https://review.opendev.org/666009
20:37:24 corvus what does it mean when osc says "(2, 'No such file or directory')" on invocation?
20:37:56 corvus eg: http://paste.openstack.org/show/753157/
20:38:20 corvus mordred: ^?
20:45:09 corvus i think that may happen if the cache file directory doesn't exist
20:45:23 corvus it would be nice if it said which directory didn't exist. that would save time.
20:45:41 corvus or just don't mask the exception
#openstack-sdks - 2019-06-19
01:34:08 openstackgerrit yanpuqing proposed openstack/python-openstackclient master: Client should parse string to boolean for value 'is_domain' https://review.opendev.org/665629
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?

Earlier   Later