| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2022-06-20 | |||
| 18:06:37 | opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack master: DNM: Test openstacksdk dependency https://review.opendev.org/c/openstack/ansible-collections-openstack/+/844859 | |
| 18:07:18 | opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack master: DNM: Test openstacksdk dependency https://review.opendev.org/c/openstack/ansible-collections-openstack/+/844859 | |
| 18:48:25 | opendevreview | Rafael Castillo proposed openstack/openstacksdk master: Allow Resource.to_dict to allow returning unknown values https://review.opendev.org/c/openstack/openstacksdk/+/843963 | |
| 19:31:40 | opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack stable/1.0.0: Moves keypair_info from cloud to proxy object https://review.opendev.org/c/openstack/ansible-collections-openstack/+/846564 | |
| 19:36:25 | opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack stable/1.0.0: Backport improvements to keypair_info https://review.opendev.org/c/openstack/ansible-collections-openstack/+/846564 | |
| 21:06:53 | opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack master: DNM: Test openstacksdk dependency https://review.opendev.org/c/openstack/ansible-collections-openstack/+/844859 | |
| 22:27:06 | opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack master: Update project module to be compatible with new sdk https://review.opendev.org/c/openstack/ansible-collections-openstack/+/839640 | |
| #openstack-sdks - 2022-06-21 | |||
| 00:09:02 | opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack master: Updates security group rule for latest sdk https://review.opendev.org/c/openstack/ansible-collections-openstack/+/846830 | |
| 07:42:16 | gtema | slaweq, amotoki: https://review.opendev.org/c/openstack/openstacksdk/+/846618 is an attempt to enable vpnaas in devstack job to test SDK, but something is still missing. Can you pls have a look once you have time? | |
| 07:52:15 | slaweq | gtema: hi, I'm not at work today but I can take a look at it tomorrow morning | |
| 07:52:23 | gtema | thks a lot | |
| 08:40:49 | seongsoocho | Hi, After the review merged, the release note's test case failed. I checked the output of ZuuL, but can't find the reason of failure. What do I do ? https://review.opendev.org/c/openstack/python-openstackclient/+/807420 | |
| 08:41:37 | gtema | https://c0050f3fce0b81a4166e-dcdb6cbb330bdac08ffee1284f86c919.ssl.cf5.rackcdn.com/807420/7/promote/promote-openstack-releasenotes/f60515b/job-output.txt | |
| 08:42:07 | gtema | this is the log. You can literally do nothing and we simply wait for next change to land and it will publish latest release notes | |
| 08:49:33 | frickler | ftr this can happen when two promote jobs run in parallel, like seems to have been the case here https://zuul.opendev.org/t/openstack/builds?job_name=promote-openstack-releasenotes&project=openstack/python-openstackclient | |
| 08:50:41 | frickler | the solution to wait for the next run to happen is the only one we have in place so far | |
| 08:55:43 | amotoki | gmann: thanks. I will look into it today. | |
| 08:59:43 | amotoki | gmann: sorry | |
| 09:00:02 | amotoki | gtema: thanks. I will look into your vpnaas zuul config today | |
| 09:00:08 | gtema | :) | |
| 09:00:21 | gtema | thanks | |
| 10:26:14 | opendevreview | Stephen Finucane proposed openstack/python-openstackclient master: image: Simplify list image parser https://review.opendev.org/c/openstack/python-openstackclient/+/846994 | |
| 13:31:37 | noonedeadpunk | hello there! I need some help with nasty thing I found. It happens in different services, like heat, and ofc reproducible with openstackclient. I bleieve it's because same approach is used in clients. So the issue is when having more then 1000 flavors, you can't create server with some of them when providing flavor name (not uuid). | |
| 13:31:55 | noonedeadpunk | Basically it goes to absent support for pagination here https://opendev.org/openstack/osc-lib/src/branch/master/osc_lib/utils/__init__.py#L269 | |
| 13:32:41 | gtema | that is the reason I am trying to switch all of those to SDK where things like that are handled generally | |
| 13:32:47 | noonedeadpunk | But what confuses me is going this path at the first place. I believe it's because usage of novaclient here https://opendev.org/openstack/python-openstackclient/src/branch/master/openstackclient/compute/v2/server.py#L1336-L1337 | |
| 13:33:25 | noonedeadpunk | and novaclient does not have find_flavor method. While openstacksdk does. | |
| 13:34:13 | gtema | agree, is messy currently | |
| 13:34:54 | gtema | feels like I need to restart work on switching OSC to use SDK | |
| 13:35:09 | noonedeadpunk | So basically I kind of lost what/where is better place to fix. As now ppl using heat just randomly fail based if flavor is in first 1000 ones or not... | |
| 13:36:09 | gtema | with heat it is going to be bit more problematic - it is an OSC plugin outside of the tree | |
| 13:36:51 | noonedeadpunk | I guess it goes all to novaclient.... need to check though... | |
| 13:37:17 | gtema | and I do not even know why it would be relevant for heat | |
| 13:37:40 | gtema | if you mean heat in the backend - yes, it is deep in core of heat itself which lib it uses | |
| 13:38:14 | noonedeadpunk | So resource creation fails with smth like `Error validating value '2C-4GB-50GB': No Flavor matching {'name': '2C-4GB-50GB'}. (HTTP 404)` | |
| 13:38:46 | noonedeadpunk | And I could reproduce that with client... | |
| 13:39:00 | noonedeadpunk | But heat is another beast to fight here | |
| 13:39:05 | gtema | yes, then this is not what we can solve ourselves. It requires fix in novaclient | |
| 13:39:30 | noonedeadpunk | basically implementing flavors find there | |
| 13:39:32 | gtema | I would say it is "conincedence" that you can reproduce it in OSC | |
| 13:39:42 | noonedeadpunk | then hopefully osc can pick that up and use... | |
| 13:39:48 | gtema | coincidence | |
| 13:40:26 | gtema | from osc pov we can fix that by switching to sdk. But in any way that problem would require novaclient fix | |
| 13:40:37 | gtema | or heat switching to SDK as well | |
| 13:40:51 | noonedeadpunk | I was thinking about heat switching to sdk tbh :D | |
| 13:41:12 | noonedeadpunk | But I assume it's not easy thing to do. | |
| 13:41:13 | gtema | yeah, all question of effort and available resources | |
| 13:41:24 | gtema | well, it is relatively easy, just lot work | |
| 13:42:26 | gtema | it even already uses SDK inside: https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os/openstacksdk.py | |
| 13:42:56 | gtema | https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os/nova.py - here you have novaclient usage | |
| 13:43:14 | gtema | so technically it is not that complex to exchange one client with another | |
| 13:45:34 | noonedeadpunk | hm, from what I can see mine usecase looks not that bad https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os/nova.py#L271-L281 | |
| 13:45:38 | noonedeadpunk | interesting | |
| 13:46:02 | gtema | yes, should be | |
| 13:46:47 | noonedeadpunk | but likely pagination just not present inside novaclient at all | |
| 13:46:56 | noonedeadpunk | likely it's easiest thing to fix then | |
| 13:47:04 | noonedeadpunk | thanks for your time gtema! | |
| 13:47:09 | gtema | welcome | |
| 13:47:24 | gtema | if I read code properly: https://opendev.org/openstack/python-novaclient/src/branch/master/novaclient/base.py#L411 | |
| 13:48:25 | gtema | and that ends in https://opendev.org/openstack/python-novaclient/src/branch/master/novaclient/v2/flavors.py#L148 | |
| 13:48:30 | gtema | and there is no word of pagination | |
| 13:49:36 | noonedeadpunk | I should rather check how it's done in sdk :) | |
| 13:50:39 | gtema | https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/resource.py#L2068 | |
| 13:51:27 | gtema | this is basic find: it tries to use name as filter and otherwise fall back to listing all and grepping through, but list by default fetches all pages | |
| 13:54:12 | noonedeadpunk | yeah, so it goes to implementing pagination in novaclient... ugh... what a disgusting thing to do | |
| 13:54:26 | noonedeadpunk | or switch heat to sdk | |
| 13:55:28 | gtema | as was discussed multiple summits and endless chats - ideally we have single API client tool that handles things just properly | |
| 13:55:41 | gtema | we all would have less mess to take care of | |
| 13:56:46 | noonedeadpunk | Yeah, so switching heat sounds like more proper solution I can be occupied with for next several days for sure. | |
| 13:57:06 | gtema | I would rather say - weeks | |
| 13:58:16 | noonedeadpunk | yeah... | |
| 13:59:15 | noonedeadpunk | And I can't even return back to finishing https://review.opendev.org/c/openstack/python-openstackclient/+/828708 :( | |
| 13:59:40 | gtema | LOL, it is as usual | |
| 14:00:27 | noonedeadpunk | ok. at least now I see several ways of going forward. All of them needs time | |
| 14:00:40 | gtema | :) | |
| 14:00:53 | gtema | generally you should not have so many flavors ;-) | |
| 14:00:55 | noonedeadpunk | and time to land as that's smth that won't be backported | |
| 14:01:45 | noonedeadpunk | 1715 to be percise. Now I'm thinking that I indeed can write super simple thing to clean out unused ones.... | |
| 14:02:26 | gtema | glad I gave you another idea. You can also increase nova pagination limit | |
| 14:04:18 | noonedeadpunk | I'm not sure where is that. I belive it should be in api-paste.ini? | |
| 14:04:35 | noonedeadpunk | and tbh 1000 is fair amount... | |
| 14:05:01 | gtema | sure, but still it is an option | |
| 14:05:49 | noonedeadpunk | yup, thanks again ! | |
| 14:05:58 | gtema | wlcm | |
| 14:14:01 | opendevreview | Artem Goncharov proposed openstack/ansible-collections-openstack master: Switch project_info to new SDK https://review.opendev.org/c/openstack/ansible-collections-openstack/+/845782 | |
| 14:27:39 | opendevreview | Artem Goncharov proposed openstack/openstacksdk master: Implement supplementary list filtering https://review.opendev.org/c/openstack/openstacksdk/+/845726 | |
| 14:28:47 | opendevreview | Artem Goncharov proposed openstack/openstacksdk master: Respect filters in list_projects https://review.opendev.org/c/openstack/openstacksdk/+/845776 | |
| 14:55:57 | noonedeadpunk | sorry, another thing.... Shouldn't list(conn.compute.servers(details=True))[0].flavor be an object rather then a simple dict? | |
| 14:56:17 | noonedeadpunk | I bet I asked that though several years ago.... | |
| 14:56:31 | noonedeadpunk | likely has smth to do with api version... | |
| 14:57:03 | gtema | an object in SDK implements dict interface | |
| 14:57:17 | noonedeadpunk | as that is empty https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/compute/v2/server.py#L111 | |
| 14:58:07 | noonedeadpunk | so basically there's no way to get flavor id or flavor name out of server? | |
| 14:58:16 | gtema | and here we may land in the microversions mess. Normally it is filled, but depending on the supported microversion you have one thing or another | |
| 14:58:41 | gtema | https://docs.openstack.org/api-ref/compute/?expanded=show-server-details-detail#show-server-details | |
| 14:58:42 | noonedeadpunk | I guess I need to set higher microversion explicitly.... | |
| 14:59:02 | gtema | with SDK you do not do this at all, SDK negotiates max supported MV by both sides | |
| 14:59:17 | gtema | but if server is old - it will not help | |
| 14:59:54 | gtema | flavor should be filled, and was filled once I looked at it last time | |
| 15:00:10 | noonedeadpunk | ok, yes, now I recall that | |