Earlier  
Posted Nick Remark
#openstack-sdks - 2022-10-26
14:02:20 opendevreview Denys Mishchenko proposed openstack/ansible-collections-openstack master: Existing images update name, visibility etc https://review.opendev.org/c/openstack/ansible-collections-openstack/+/862565
14:02:26 fungi what would compute:get_all normally return? is that the list of server instances?
14:02:33 gtema yes
14:02:46 fungi so essentially `openstack server list`
14:02:54 gtema correct
14:03:01 fungi thanks
14:03:06 opendevreview Jiri Podivin proposed openstack/cliff master: Removing helper functions providing Python < 3.3 compatibility https://review.opendev.org/c/openstack/cliff/+/862689
14:03:11 gtema thank you fungi
14:03:20 gtema I learned something new about sdk today
14:04:26 fungi i'll see what more we can get from my contact there, i just wanted to make sure i had a more complete picture of what/where the problem is before reaching out
14:05:30 gtema sure. This rackspaceauth is a thing that we would also need to install into sdk jobs, but it should be not an issue
14:06:20 fungi well, since it's been an advertised option (going back at least 5 years in the published sdk docs), double-checking that it can be made to work would be good anyway
14:06:38 fungi and if it can't, then a docs update is in order
14:07:19 gtema at least now I eventually see where clarkb's problem with cinder may lay - in this type of auth project_id is not being set and we try to concat None
14:07:28 fungi but i'll see if he's willing to give us a password for the account too, so that both paths can be tried
14:07:45 gtema awesome, thanks
14:09:13 fungi gtema: fwiw, with opendev's tenants we don't use api_key, we set password and project_id in our clouds.yaml files
14:09:54 gtema yes, I have seen that, but clark mentioned he was trying in venv so I assumed he may be making few tweaks
14:10:45 fungi nah, the venvs we've been talking about still rely on the same /etc/openstack/clouds.yaml file we install on the server where we're running the client
14:11:31 fungi though we do end up needing to use an old version of the sdk and we pass --os-volume-api=1 on the client command line in order to make it work
14:11:47 gtema ok, then if "cinderclient.exceptions.UnsupportedVersion: Invalid client version '2.0'. Major part should be '3'" is the broken thing it is due to cinderclient having dropped support
14:12:20 gtema same is for v1 - it was dropped in cinderclient
14:12:48 fungi i have python-cinderclient==4.0.1 in both a working and broken venv
14:13:03 gtema we can try to implement here raw API requests (or hope SDK v1 is still working)
14:13:15 gtema but is that the exception you get?
14:13:27 fungi the problem i'm seeing with the non-working (newer sdk) venv is a "Not Found (HTTP 404)" response from the cloud
14:13:31 opendevreview Stephen Finucane proposed openstack/python-openstackclient master: compute: Add '--no-network', '--auto-network' flags https://review.opendev.org/c/openstack/python-openstackclient/+/862680
14:14:19 gtema for something like volume list?
14:14:36 fungi yes
14:15:07 fungi if i downgrade openstacksdk from 0.48.0 to 0.41.0 then volume list works with the same command-line options and configuration
14:15:26 fungi i haven't finished bisecting between those yet
14:15:28 gtema wow, but that is very very old
14:15:36 fungi yes, we had to go back that far to make it work
14:15:58 gtema anyway, in order to reproduce I need to pass through "Policy doesn't allow volume:get_all to be performed" which I get now
14:15:59 fungi rather, we started pinning when it broke and haven't been able to upgrade
14:16:45 fungi and yes, trying to use cinderclient as a workaround is problematic in the way you noted
14:16:58 fungi (newer cinderclient dropped old api versions)
14:17:53 gtema that sucks quite heavily - supporting such old things is terribly complex
14:19:00 fungi thankfully most of the problem impact is to volume management, which we only do manually. it hasn't adversely impacted stuff like nodepool since it doesn't need to care about the volume api
14:20:00 fungi so we've been able to get by with custom venvs containing really old libs for the times when we need to add/remove/replace volumes for our persistent control plane servers
14:20:17 fungi it's not ideal though, of course
14:20:29 gtema which osc-lib and osc ver are installed? I can't get matching combo
14:21:56 fungi i'm going to make fresh venvs first just to make sure i have a consistent reproducer
14:22:14 gtema I mean the one which is working
14:22:29 gtema with older versions, cause sdk==0.41.0 is not working with "any" OSC
14:22:36 gtema and older OSC falls on osc-lib
14:23:07 gtema and finally falling on "module 'collections' has no attribute 'MutableMapping'"
14:25:16 fungi yeah, that's why i'm trying to reproduce with clean venvs first, because i'd like to know how to create an equivalent of the working reference venv i have from scratch
14:25:28 gtema ok, thks
14:26:44 fungi also note that the venvs in question are built for python 3.6 because they're on an ubuntu 18.04 lts (bionic) server
14:26:57 fungi looks like i need to force downgrade cryptography because of that
14:34:14 fungi python3.6 -m venv foo
14:34:18 fungi foo/bin/pip install -U pip setuptools wheel
14:34:21 fungi foo/bin/pip install openstackclient python-openstackclient==3.17.0 openstacksdk==0.41.0 python-cinderclient==4.0.1
14:34:24 fungi sudo foo/bin/openstack --os-cloud=openstackci-rax --os-region-name=DFW --os-volume-api=1 volume list
14:34:35 fungi gtema: that ^ reproduces a working one for me
14:35:00 gtema ugh, now I need to find somewhere py36 for me ;-)
14:35:01 gtema thanks
14:36:03 fungi i'm winding forward with openstacksdk versions to find the one where the first breakage occurs
14:37:20 fungi huh, so i was able to wind forward to openstacksdk==0.48.0 and it continues working
14:37:58 fungi also it may be reproducible on newer python interpreters, i haven't tried yet
14:38:58 gtema okay, in any way now I nearly always fall on policies
14:39:19 gtema I mean either some other py exception of policy
14:40:31 fungi i'm able to make i work with 0.102.0 in fact
14:40:54 gtema lol - so something different in playing a role
14:41:06 gtema welcome in the dependency hell
14:42:27 fungi yes, i'm trying to play with other dependency variables now
14:43:07 gtema what is the issue with v2 itself?
14:43:19 gtema maybe fixing this will cost less then making v1 work
14:43:20 fungi not completely implemented in rackspace
14:43:24 gtema ah, ok
14:43:45 fungi at least that's my understanding, but i can get a more specific error
14:45:25 fungi what was the cinderclient version where v2 api support was dropped?
14:45:47 gtema roughly a year ago
14:46:05 gtema https://opendev.org/openstack/python-cinderclient/commit/6ebee33bf219d42fcd0d4bf2a8c0819bddb24f3c
14:47:05 fungi yeah, if i pin python-cinderclient<8 i only get the deprecation warning for v2
14:48:04 fungi adding --debug, it looks like it's trying to get /v2/610275/610275/volum
14:48:31 fungi er, it's trying to get /v2/$id/$id/volume/detail
14:48:42 fungi from the block storage api endpoint
14:48:43 gtema ok, seems like a bug
14:48:50 fungi and that returns a 404 not found
14:50:18 fungi server list uses /v2/$id/servers/detail so i guess the doubled project id in the url is a problem
14:51:11 gtema yeah, on the other side v2 cinder is not present in the "service_catalog" - explicitly in the quotes since this is a thing on its own
14:51:56 gtema and using normal OSC it fails to find volumev2 endpoint for region
14:54:41 fungi right, i got that as well once i pinned back a bit
14:56:34 frickler fungi: checking on bridge we set block_storage_endpoint_override to .../v2/610275. maybe drop the last part of that
14:56:45 fungi ooh, good eye
14:56:56 opendevreview Dmitriy Rabotyagov proposed openstack/python-openstackclient master: Implement server and host evacuate commands https://review.opendev.org/c/openstack/python-openstackclient/+/828708
14:57:56 frickler I haven't found a cli option to override that override
14:58:14 gtema in cli no way
14:58:40 gtema the problem is that this override is only influencing SDK, but not cinderclient itself
14:59:03 fungi frickler: good call. with that edit i'm able to get it work with latest sdk and cli installable on python 3.6, as long as i pin python-cinderclient<5
14:59:30 fungi i'll push up a change to our clouds.yaml since that simplifies what we need to do to make the cli work
14:59:50 gtema that all sounds like a very dirty hack ;-)
15:03:45 frickler with the same cap it also works on the new bridge with py3.10
15:04:02 opendevreview HaeIYoon proposed openstack/openstacksdk master: Add image metadef object operations https://review.opendev.org/c/openstack/openstacksdk/+/858350
15:04:12 frickler hack for maybe-a-non-openstack cloud, but progress anyway
15:04:41 gtema this is exactly what I always want to say - this doesn't feel like openstack cloud
15:05:28 frickler though admittedly there may be an old private cloud running icehouse or similar that might alse need the capped cinderclient
15:06:03 frickler *also

Earlier   Later