| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2022-10-25 | |||
| 17:48:32 | noonedeadpunk | gtema: hey! I'm quite ashamed but on PTG I was side-pinged and missed beginning of the discussion regarding search_xxx - payed attention only starting from words - "it affects only ansible collections"... So basically right now we're working on implementation of roles for images lifecycle. And zuul folks were also interested in this approach as contrary to nodepool-builder | |
| 17:48:56 | noonedeadpunk | but eventually faced this topic and how to search for images with new sdk/collections | |
| 17:49:56 | noonedeadpunk | Basically we (under we I mean arddennis) have some time to help out on implementation, but would be great if you could somehow point to the right direction | |
| 17:54:33 | noonedeadpunk | I'm not sure there was a decision made on what direction to move (either implement search logic or a generic search_resource) but generic search sound like a good idea at the moment comparing to moving logic to collections (or at least more clean one) | |
| 17:58:20 | noonedeadpunk | But I think it's worth syncing efforts so that we won't dig into the wrong direction | |
| 17:59:08 | noonedeadpunk | (or the one you're trying to get rid of for quite a while now) | |
| 18:01:46 | opendevreview | Violet Kurtz proposed openstack/python-openstackclient master: Moved hypervisor to the SDK https://review.opendev.org/c/openstack/python-openstackclient/+/858366 | |
| 18:05:11 | opendevreview | Merged openstack/ansible-collections-openstack master: Refactored baremetal_node and baremetal_node_info modules https://review.opendev.org/c/openstack/ansible-collections-openstack/+/854113 | |
| 18:10:03 | 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 | |
| 18:15:54 | gtema | noonedeadpunk: so you stick to Ansible usecase or you are searching for also regular SDK interface for that? | |
| 18:32:39 | noonedeadpunk | gtema: ansible usecase now | |
| 18:35:13 | noonedeadpunk | so for rotation we need to get images with specific tags/properties and verify them. So classic search basically | |
| 18:39:40 | noonedeadpunk | verify in terms to check if they're used by any server or not and if not delete them, otherwise hide | |
| 18:45:43 | noonedeadpunk | writing it makes me think how optimal end result would be though... as sounds as quite few loops which ansible not good at | |
| 18:47:48 | noonedeadpunk | but I want it to be native zuul job in periodic pipeline (for internal zuul), so it's either just ansible or make ansible module out of this which won't be much better as we still will face earch I believe | |
| 18:47:54 | noonedeadpunk | *face search | |
| 18:50:04 | gtema | I would rather create special module packing all functionality | |
| 18:50:44 | noonedeadpunk | and move search logic to it? | |
| 18:51:02 | gtema | Not that, i mean all iterations | |
| 18:53:46 | noonedeadpunk | well... several things here why I thought that plain ansible would work - this can be re-used in many places and help other operators to get fresh images when needed. In OSA we also mess up with images for octavia/magnum/trove/etc. So we can easily re-use that | |
| 18:54:25 | noonedeadpunk | next is permissions - most of oprations won't require admin, but rotation is. So we can provide different credentials to some tasks/roles | |
| 18:55:09 | noonedeadpunk | and actually help out and get collection better :) | |
| 18:57:33 | noonedeadpunk | but yeah, I do understand why such module would be faster/easier. | |
| 18:58:45 | noonedeadpunk | just how re-usable it would be (likely not) | |
| 19:55:59 | opendevreview | Merged openstack/ansible-collections-openstack master: Refactored baremetal_node_action module https://review.opendev.org/c/openstack/ansible-collections-openstack/+/854357 | |
| 20:41:22 | opendevreview | Merged openstack/ansible-collections-openstack master: Refactored baremetal_port and baremetal_port_info modules https://review.opendev.org/c/openstack/ansible-collections-openstack/+/854569 | |
| #openstack-sdks - 2022-10-26 | |||
| 01:52:03 | opendevreview | Daniel Wilson proposed openstack/python-openstackclient master: Use the compute SDK in server list https://review.opendev.org/c/openstack/python-openstackclient/+/861546 | |
| 02:07:52 | opendevreview | Daniel Wilson proposed openstack/openstacksdk master: Accept queries when listing migrations https://review.opendev.org/c/openstack/openstacksdk/+/862664 | |
| 02:53:27 | opendevreview | Daniel Wilson proposed openstack/python-openstackclient master: Use the compute SDK in usage commands https://review.opendev.org/c/openstack/python-openstackclient/+/861801 | |
| 05:50:48 | opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack master: Updates volume for 2.0.0 https://review.opendev.org/c/openstack/ansible-collections-openstack/+/853749 | |
| 07:51:23 | opendevreview | Merged openstack/ansible-collections-openstack master: Updates volume for 2.0.0 https://review.opendev.org/c/openstack/ansible-collections-openstack/+/853749 | |
| 08:03:06 | opendevreview | Jakob Meng proposed openstack/ansible-collections-openstack master: Change subnets_info module to work with new SDK https://review.opendev.org/c/openstack/ansible-collections-openstack/+/857041 | |
| 09:26:16 | opendevreview | Stephen Finucane proposed openstack/python-openstackclient master: Added "openstack image metadefs namespace list" command https://review.opendev.org/c/openstack/python-openstackclient/+/854557 | |
| 09:56:42 | opendevreview | Merged openstack/openstacksdk master: Improve swift headers handling https://review.opendev.org/c/openstack/openstacksdk/+/860007 | |
| 10:11:29 | opendevreview | Merged openstack/python-openstackclient master: volume: Volume names are optional https://review.opendev.org/c/openstack/python-openstackclient/+/857670 | |
| 10:27:34 | opendevreview | Merged openstack/ansible-collections-openstack master: Change subnets_info module to work with new SDK https://review.opendev.org/c/openstack/ansible-collections-openstack/+/857041 | |
| 10:32:55 | opendevreview | Stephen Finucane proposed openstack/python-openstackclient master: compute: Add '--no-network', '--auto-network' flags https://review.opendev.org/c/openstack/python-openstackclient/+/862680 | |
| 11:31:12 | opendevreview | Merged openstack/python-openstackclient master: Added "openstack image metadefs namespace list" command https://review.opendev.org/c/openstack/python-openstackclient/+/854557 | |
| 12:10:11 | opendevreview | Stephen Finucane proposed openstack/openstacksdk master: compute: Add functional tests for volume attachments https://review.opendev.org/c/openstack/openstacksdk/+/822314 | |
| 13:05:08 | opendevreview | Jakob Meng proposed openstack/ansible-collections-openstack master: Refactored ci script with shellcheck suggestions and install collections https://review.opendev.org/c/openstack/ansible-collections-openstack/+/861955 | |
| 13:14:28 | opendevreview | Jiri Podivin proposed openstack/cliff master: Removing helper functions providing Python < 3.3 compatibility https://review.opendev.org/c/openstack/cliff/+/862689 | |
| 13:15:05 | opendevreview | Jiri Podivin proposed openstack/cliff master: Clarification of the algorithm used https://review.opendev.org/c/openstack/cliff/+/862690 | |
| 13:45:59 | frickler | not sure if everyone is subscribed, discussion about the storyboard issue is now happening here https://lists.opendev.org/pipermail/service-discuss/2022-October/000370.html | |
| 13:47:22 | fungi | it looks like a lot of folks who were in here via the matrix-oftc bridge dropped around 08:05 utc and haven't rejoined yet | |
| 13:48:53 | frickler | ah, that explains why gtema dropped from the publiccloud meeting | |
| 13:49:43 | gtema | hmm, I was even posting during the meeting | |
| 13:49:48 | frickler | I only can recommend not to use that bridge, some colleagues of mine do and see regular disconnects | |
| 13:49:59 | fungi | gtema: now we see you | |
| 13:50:17 | fungi | looks like it must have fixed itself and the bridge auto-joins you again as soon as you say something new | |
| 13:50:26 | gtema | cool, I was permanently here and seeing everything posted here | |
| 13:50:32 | frickler | gtema: "full house today" at 08:02 was the last thing we read from you | |
| 13:50:53 | opendevreview | Artom Lifshitz proposed openstack/python-openstackclient master: Improve `server dump create` helptext https://review.opendev.org/c/openstack/python-openstackclient/+/862696 | |
| 13:51:01 | gtema | funny, but this half-sync is really confusing | |
| 13:51:49 | fungi | gtema: while you're here, just to get some additional clarification on the rackspace api_key extension... are you saying you were trying with the configuration documented here and it wasn't able to authenticate arbitrary api calls with the resulting session? https://docs.openstack.org/openstacksdk/latest/user/config/vendor-support.html#rackspace | |
| 13:51:51 | gtema | this is also not the first time - jm1 was already telling similar to me - being in element he could see everything what I post, but it was never reaching IRC | |
| 13:52:43 | gtema | fungi - interesting. I was not trying auth_type cause I was sure it is something only present in the rax hacks | |
| 13:53:09 | fungi | yeah, the matrix bridges can end up in strange half-connected states where you see things inbound from irc but nothing you say gets back to irc (but other users of the bridge still see what you say because that doesn't have to round-trip through itc | |
| 13:53:18 | fungi | er, round-trip through irc | |
| 13:54:12 | gtema | fungi - rackspace_apikey is not implemented part of the keystoneauth lib | |
| 13:54:20 | fungi | gtema: as noted in the openstacksdk docs, to use auth_type: rackspace_apikey you do need to install the rackspaceauth plugin for ksa | |
| 13:54:25 | gtema | https://github.com/rackerlabs/rackspace-auth-openstack | |
| 13:54:47 | gtema | so honestly I have no clue how that supposed to work without this lib being installed | |
| 13:55:08 | gtema | and it has entry_points - trying now to install it | |
| 13:55:51 | fungi | gtema: you're installing https://pypi.org/project/rackspaceauth right? | |
| 13:57:27 | gtema | ha, https://pypi.org/search/?q=rackspaceauth - try to guess which one to install | |
| 13:57:28 | fungi | just making sure, since it doesn't look like the package on pypi is the same as the repo you linked in github | |
| 13:57:46 | gtema | exactly, with that one I passed one step further | |
| 13:58:04 | fungi | specifically, the package the openstacksdk docs say to pip install | |
| 13:58:56 | gtema | right - I never seen this part, so was not sure | |
| 13:59:07 | gtema | but now I am through the auth and get: Policy doesn't allow compute:get_all to be performed. (HTTP 403) | |
| 14:00:56 | gtema | pretty much nothing is allowed, either api key didn't receive right permissions or I use wrong project | |
| 14:01:27 | fungi | oh, is there still some question as to whether the tenant/project id is correct? | |
| 14:01:52 | gtema | at least this tenant/project is reported as the only one in the auth response | |
| 14:01:57 | gtema | so it should be right | |
| 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 | |