Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2020-11-03
11:05:42 gtema no problem
11:05:51 stephenfin (The main problem was the performance issue of the fetch-update proxy calls, btw. The rest were nits and could be ignored)
11:05:59 gtema btw, regarding your comment on delete_flavor_extra_specs_property calling get_Flavor 2 times
11:06:09 gtema are you sure? Cause it actually should not be the case
11:06:42 stephenfin I'm not sure, no. I was just reading the the openstacksdk code and it seemed like it would do a fetch each time
11:06:49 stephenfin Perhaps I'm misreading it?
11:06:53 gtema nope, it should not
11:07:17 gtema https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/proxy.py#L305
11:07:48 gtema this is the get_resource, which is in the end being invoked to decide what we pass to it: id or instance of the object.
11:07:58 gtema in reality it doesn't invoke the fetch again
11:08:54 stephenfin You're calling it with flavor.id though
11:09:09 gtema yes, and it is enough for it
11:09:15 stephenfin which means you trigger this path, I think? https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/proxy.py#L327-L331
11:09:44 stephenfin though i didn't check if that actually fetches things
11:09:45 gtema if I pass complete object it has no advantage, but disadvantage of passing more data to other function (especially ugly in tests)
11:10:14 gtema even here no request is being send
11:10:41 stephenfin oh, okay, I wasn't expecting that
11:11:09 gtema without commit this is not doing anything
11:11:13 gtema no problem with that
11:11:14 stephenfin in that case, ignore that comment :) sorry for the confusion
11:11:24 gtema no problem
11:12:27 gtema I am actually since perhaps a year confused on pretty much that issue - passing more than require is not good (especially for huge objects), but passing less cause some extra functions
11:13:16 stephenfin yeah, the Resource model and general lazy loading concept it uses does take a bit of time to wrap your head around
11:13:34 gtema yes, it's woodoo
11:31:06 dulek Hi! We're using openstacksdk as our main tool to connect to OpenStack APIs. When there's high load we start too see "urllib3.connectionpool [-] Connection pool is full, discarding connection" warnings.
11:31:46 dulek While it seems those are harmless, is there a way to increase pool size? How deep should I look?
11:32:00 gtema dulek, what exactly are you doing?
11:32:41 dulek gtema: A ton of calls to Neutron and Octavia. Kuryr is reacting to events in K8s, so the number of events being handled might be massive.
11:33:12 gtema hmm, not that I am aware of any explicit connection pools we have
11:33:51 gtema could be it is coming from keystonauth
11:34:26 dulek gtema: Yeah, or even from requests. Okay, I'll try to dig deeper.
11:34:54 gtema I hope there might be some logs pointing where it is really coming from
11:39:52 gtema dulek - I haven't found any reference in SDK/Keystone for using connectionpools at all
11:40:13 dulek gtema: There's this: https://github.com/openstack/keystoneauth/blob/1f0412a042103009c5a95230e058d08e5bd91fa1/keystoneauth1/session.py#L1423
11:40:15 gtema seems you might then face the defaults
11:40:40 dulek Yup!
11:40:42 gtema aah, from adapters
11:45:56 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/python-openstackclient master: Add "fields" parameter to ListPort query https://review.opendev.org/754117
11:46:14 dulek It doesn't seem trivial to pass bigger pool there.
12:10:51 openstackgerrit Cédric Jeanneret (Tengu) proposed openstack/keystoneauth stable/train: Cleanup session on delete https://review.opendev.org/760911
12:21:46 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Switch flavor ops in the cloud layer to proxy https://review.opendev.org/761124
12:58:50 openstackgerrit Merged openstack/python-openstackclient master: Add 'openstack server migration list --type' option https://review.opendev.org/757874
13:32:54 openstackgerrit Hervé Beraud proposed openstack/microversion-parse master: Use Python 3.8 as the default runtime for tox https://review.opendev.org/761145
14:08:27 openstackgerrit Merged openstack/microversion-parse master: Use Python 3.8 as the default runtime for tox https://review.opendev.org/761145
15:37:04 lbragstad follow up stable review if folks are interested in taking a look https://review.opendev.org/#/c/746968/
15:59:14 openstackgerrit Cédric Jeanneret (Tengu) proposed openstack/keystoneauth stable/train: Cleanup session on delete https://review.opendev.org/760911
17:22:47 openstackgerrit Stephen Finucane proposed openstack/python-openstackclient master: compute: Format list of tags for 'server list' https://review.opendev.org/761205
#openstack-sdks - 2020-11-04
00:28:41 openstackgerrit Merged openstack/python-openstackclient master: Compute: Add user id support for keypair https://review.opendev.org/576507
07:33:57 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Switch flavor ops in the cloud layer to proxy https://review.opendev.org/761124
09:07:38 openstackgerrit Hervé Beraud proposed openstack/microversion-parse master: Use py3 as the default runtime for tox https://review.opendev.org/761323
09:08:14 openstackgerrit Hervé Beraud proposed openstack/os-api-ref master: Use py3 as the default runtime for tox https://review.opendev.org/761325
09:54:56 openstackgerrit Hervé Beraud proposed openstack/os-api-ref master: Use TOX_CONSTRAINTS_FILE https://review.opendev.org/761367
10:23:58 openstackgerrit jayaditya gupta proposed openstack/python-openstackclient master: Add a few selectable fields to the "openstack server list" output https://review.opendev.org/741181
10:25:54 openstackgerrit jayaditya gupta proposed openstack/python-openstackclient master: Add a few selectable fields to the "openstack server list" output https://review.opendev.org/741181
11:07:21 stephenfin gtema: FYI https://review.opendev.org/#/c/760906/8/openstackclient/compute/v2/flavor.py@344
11:14:48 gtema stephenfin, thanks. will have a look later today. I was pretty sure for me locally it was working, but will doublecheck
11:17:06 gtema yes, right. Can reproduce it
11:20:52 openstackgerrit Stephen Finucane proposed openstack/osc-lib master: formatters: Cast columns before outputting https://review.opendev.org/761394
11:20:56 stephenfin gtema: Thoughts? ^
11:21:24 stephenfin It's kind of dumb, but the alternative is to do this on a case-by-case basis (I saw the same issue when trying to resolve issues with 'server show' and 'server list')
11:22:30 gtema yeah, worth a try
11:27:32 openstackgerrit Merged openstack/os-api-ref master: Use TOX_CONSTRAINTS_FILE https://review.opendev.org/761367
14:53:54 openstackgerrit Stephen Finucane proposed openstack/cliff master: columns: Make 'FormattableColumn' comparable https://review.opendev.org/761421
15:14:09 stephenfin gtema: dtantsur: I'd like to get that merged and released this week, if possible, so I can keep working on fixing up various compute-related OSC bugs ^
15:14:31 gtema ok
15:18:06 openstackgerrit Stephen Finucane proposed openstack/cliff master: columns: Make 'FormattableColumn' comparable https://review.opendev.org/761421
15:30:33 openstackgerrit Stephen Finucane proposed openstack/osc-lib master: formatters: Cast columns before outputting https://review.opendev.org/761394
15:30:37 openstackgerrit Stephen Finucane proposed openstack/osc-lib master: tox: Set 'ignore_basepython_conflict' https://review.opendev.org/761428
17:00:19 openstackgerrit Stephen Finucane proposed openstack/python-openstackclient master: Make 'FormattableColumn' subclasses comparable https://review.opendev.org/761447
17:46:12 openstackgerrit Stephen Finucane proposed openstack/python-openstackclient master: Make 'FormattableColumn' subclasses comparable https://review.opendev.org/761447
17:47:03 stephenfin I don't know if we want to wait for cliff and osc-lib releases, but if not that patch should clean up the tests and let me keep working on the compute issues in a sane manner :) ^
19:59:36 openstackgerrit Merged openstack/osc-lib master: zuul: Stop testing against Tempest https://review.opendev.org/760343
21:27:56 openstackgerrit Merged openstack/osc-lib master: formatters: Cast columns before outputting https://review.opendev.org/761394
21:38:28 openstackgerrit Merged openstack/osc-lib master: tox: Set 'ignore_basepython_conflict' https://review.opendev.org/761428
#openstack-sdks - 2020-11-05
05:48:00 openstackgerrit zhufl proposed openstack/openstacksdk master: Fix invalid assertIsNotNone statement https://review.opendev.org/761053
08:54:24 openstackgerrit jayaditya gupta proposed openstack/python-openstackclient master: Add a few selectable fields to the "openstack server list" output https://review.opendev.org/741181
10:06:18 stephenfin gtema: amotoki: Thanks for the reviews :) Any chance you could look at https://review.opendev.org/#/c/761421/ too?
10:06:59 gtema stephenfin - sure. I requested release of osc-lib
10:07:22 noonedeadpunk o/
10:07:50 stephenfin gtema++ great, thanks :)
10:07:55 noonedeadpunk I'm trying to get why `openstackclient/volume/v2` is used and where does it comes from...
10:08:43 noonedeadpunk as it seems it has limitations v3 should not have, but kind of v3 is just empty for me
10:09:09 openstackgerrit Stephen Finucane proposed openstack/osc-lib stable/victoria: zuul: Stop testing against Tempest https://review.opendev.org/761525
10:09:22 gtema noonedeadpunk - mostly it comes from whatever version is being pointed in the service catalog (service_type=volume)
10:09:31 gtema normally operators forget to switch it to v3
10:09:42 noonedeadpunk well, I have both v2 and v3
10:10:06 gtema yes, a well known practice to have: volume, volumev2, volumev3
10:10:22 gtema look where the volume type is pointing you to
10:10:25 noonedeadpunk the most thing that concerns me is http://paste.openstack.org/show/799728/
10:10:54 gtema this is another interesting case: v2=v3 in the CLI
10:11:06 noonedeadpunk aha
10:12:19 gtema https://opendev.org/openstack/python-openstackclient/src/branch/master/setup.cfg#L662
10:12:20 noonedeadpunk well, I think it's not... What I'm trying to do - volume resize when it's in-use.
10:12:35 noonedeadpunk So client has check https://opendev.org/openstack/python-openstackclient/src/branch/master/openstackclient/volume/v2/volume.py#L608
10:12:56 noonedeadpunk however it's not true for modern cinder https://opendev.org/openstack/cinder/src/branch/stable/train/cinder/volume/manager.py#L2766
10:13:06 noonedeadpunk but true for v2 I guess
10:13:37 noonedeadpunk Not sure what's the best way to workaround here...
10:16:16 openstackgerrit Stephen Finucane proposed openstack/osc-lib master: Add Python3 wallaby unit tests https://review.opendev.org/750335
10:18:44 noonedeadpunk well, or not....
10:20:57 noonedeadpunk it is https://opendev.org/openstack/cinder/src/branch/master/cinder/api/openstack/rest_api_version_history.rst#user-content-section-39

Earlier   Later