Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2022-10-26
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
15:06:21 gtema sooner or later we will drop cinderclient from osc, but we can't really test all of those things
15:06:28 frickler so possibly still worth fixing that dependency
15:06:36 frickler and I agree about testing and all that
15:07:06 frickler just dreaming about an ideal world, that still should be possible to work
15:07:34 fungi https://review.opendev.org/c/opendev/system-config/+/862706 Correct block_storage_endpoint_override for rax
15:07:53 gtema the bigger question for me is that such clouds most likely run on py2, how should we be able to make this running if admin want to use newer OSC
15:09:04 frickler fungi: I think that comment about v1 is wrong. this is about the v2 api and at least "volume list" works fine for me with v2
15:10:10 frickler gtema: for the use case I'm thinking about, the client would be running a modern system, just talking to the API of an old cloud
15:11:05 gtema I know, it just so frustrating and funny at the same time
15:11:17 fungi frickler: oh, you're right!
15:11:20 fungi amending
15:11:48 frickler also capping cinderclient\<8 seems to be enough
15:11:57 fungi yep, i was about to test that
15:14:25 fungi okay, amended
15:14:43 fungi also confirmed that <8 works if i drop the v1 override from the command
15:15:31 fungi remains to be seen if i'll be able to do things like server attach/detach now, but at least volume list is working
15:15:37 fungi i'll play around with it a bit more
15:34:57 opendevreview Stephen Finucane proposed openstack/python-openstackclient master: compute: Fix '--network none/auto' handling https://review.opendev.org/c/openstack/python-openstackclient/+/862730
15:35:01 opendevreview Stephen Finucane proposed openstack/python-openstackclient master: compute: Add missing microversion check for networks https://review.opendev.org/c/openstack/python-openstackclient/+/862731
17:38:26 opendevreview Merged openstack/ansible-collections-openstack master: Refactored ci script with shellcheck suggestions and install collections https://review.opendev.org/c/openstack/ansible-collections-openstack/+/861955
17:49:31 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:20:34 opendevreview Jakob Meng proposed openstack/ansible-collections-openstack master: Always remove temporary files in volume's integration test https://review.opendev.org/c/openstack/ansible-collections-openstack/+/862741
20:06:17 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
20:22:00 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
21:04:22 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
#openstack-sdks - 2022-10-27
06:58:16 opendevreview Jiri Podivin proposed openstack/cliff master: Clarification of the algorithm used https://review.opendev.org/c/openstack/cliff/+/862690
07:03:00 opendevreview Jakob Meng proposed openstack/ansible-collections-openstack master: Run Ansible devel branch job on Python 3.10 https://review.opendev.org/c/openstack/ansible-collections-openstack/+/856987
07:23:47 opendevreview Jakob Meng proposed openstack/ansible-collections-openstack master: Always remove temporary files in volume's integration test https://review.opendev.org/c/openstack/ansible-collections-openstack/+/862741
08:47:16 opendevreview Jiri Podivin proposed openstack/cliff master: Clarification of the algorithm used https://review.opendev.org/c/openstack/cliff/+/862690
09:10:16 opendevreview Jakob Meng proposed openstack/ansible-collections-openstack master: Always remove temporary files in volume's integration test https://review.opendev.org/c/openstack/ansible-collections-openstack/+/862741
10:02:16 opendevreview Jakob Meng proposed openstack/ansible-collections-openstack master: Run Ansible devel branch job on Python 3.10 https://review.opendev.org/c/openstack/ansible-collections-openstack/+/856987
12:13:00 opendevreview Jakob Meng proposed openstack/ansible-collections-openstack master: Run Ansible devel branch job on Python 3.10 https://review.opendev.org/c/openstack/ansible-collections-openstack/+/856987
12:13:34 opendevreview Jakob Meng proposed openstack/ansible-collections-openstack master: Run Ansible devel branch job on Python 3.10 https://review.opendev.org/c/openstack/ansible-collections-openstack/+/856987
12:30:36 opendevreview Jakob Meng proposed openstack/ansible-collections-openstack master: Run *-devstack-ansible-devel job on Ubuntu 22.04 LTS (Jammy Jellyfish) https://review.opendev.org/c/openstack/ansible-collections-openstack/+/856987
12:31:34 opendevreview Jakob Meng proposed openstack/ansible-collections-openstack master: Run *-devstack-ansible-devel job on Ubuntu 22.04 LTS (Jammy Jellyfish) https://review.opendev.org/c/openstack/ansible-collections-openstack/+/856987
12:34:47 opendevreview Jakob Meng proposed openstack/ansible-collections-openstack master: Run *-devstack-ansible-devel job on Ubuntu 22.04 LTS (Jammy Jellyfish) https://review.opendev.org/c/openstack/ansible-collections-openstack/+/856987
15:48:56 opendevreview Merged openstack/ansible-collections-openstack master: Always remove temporary files in volume's integration test https://review.opendev.org/c/openstack/ansible-collections-openstack/+/862741
16:02:34 opendevreview Merged openstack/ansible-collections-openstack master: Run *-devstack-ansible-devel job on Ubuntu 22.04 LTS (Jammy Jellyfish) https://review.opendev.org/c/openstack/ansible-collections-openstack/+/856987
18:36:55 ard_ hey, I am working on a https://review.opendev.org/c/openstack/ansible-collections-openstack/+/862565 and have several question which I can't answer myself. According to https://docs.openstack.org/api-ref/image/v2/index.html?expanded=update-image-detail there is a set of image properties which can't be updated and this will result in 403 reply. The set I believe is here: https://github.com/openstack/glance/blob/master/etc/schema-image.json
18:36:55 ard_ and this does include kernel_id and ramdisk_id . At the same time version of the script tries to change them if such params defined and differs from the present image.
18:38:26 ard_ at the same time min_disk and min_ram are not tried to be updated. Am I missing something?
19:37:44 ard_ jm1: regarding image.update_image with id and image object. If you send image object request.body being produced with {'op': 'remove', 'path': '/stores'} and lots of properties which aren't planned to touch. Because they are correct in existing image. openstacksdk==0.102.0 So my change has this strange workaround https://review.opendev.org/c/openstack/ansible-collections-openstack/+/862565/8/plugins/modules/image.py#585
19:53:39 ard_ Here is a little bit more details: https://paste.opendev.org/show/817361/ So does it means that update args should contain all properties to not attempt removing them? Then the logic in the module is not correct. Otherwise there is an issue in sdk version .0.102.0
#openstack-sdks - 2022-10-28
07:05:48 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
07:34:38 jm1 ard_: o/ lets ask gtema about this :D
07:35:02 jm1 gtema: update functions such as update_image take a image object or id as first parameter
07:35:33 gtema yes, or something like a dict representing object
07:35:43 jm1 gtema: iiuc when an image object is given, then proxy class will take all other update_image args and assign them to the image object
07:35:46 gtema {"id": "fakeid", "name": "fakename"}
07:37:08 jm1 gtema: ard_'s issue seems to be that this image+updated-args object is passed to glance api
07:38:09 jm1 gtema: from ard_'s description is looks like glance raises an error because it gets stuff which cannot be updated
07:38:33 jm1 gtema: is this excepted?
07:39:01 gtema not really
07:39:15 gtema https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/tests/functional/image/v2/test_image.py#L69 - we test changing image name in func tests
07:39:27 jm1 gtema: maybe the issue is here: "and this does include kernel_id and ramdisk_id . At the same time version of the script tries to change them if such params defined and differs from the present image."
07:40:32 gtema it should not be the case. If you pass as first param whole image it should only update change attrs
07:40:56 gtema but image is specific in that it does things differently and tries to construct json patch
07:41:11 ard_ I tried to debug and see different body in api calls
07:42:16 gtema would be good if you give me some reproduce case (small sdk script)
07:43:07 ard_ the params are actually updated, when those 'op': 'remove' objects are added. It just complains with 409 error from api
07:43:38 ard_ give me 10 minutes
07:43:52 gtema no hurry, I am going for meeting now anyway
07:48:09 jm1 ard_: so we have different issues here? the kernel_id/ramdisk_id issue is separate from the image.id/image issue?
07:48:49 jm1 ard_: reading the glance api doc i agree with you that updating kernel_id/ramdisk_id is not going to work: "An attempt to modify any of the “base” image properties that are managed by the Image Service. These are the properties specified as read only in the Image Schema."
07:52:47 opendevreview Jakob Meng proposed openstack/ansible-collections-openstack master: [DNM] Image update test https://review.opendev.org/c/openstack/ansible-collections-openstack/+/862864
07:53:00 ard_ jm1: yes, sorry that I brought multiple questions at the same time. Yes, it is separate and should not be tried to be updated. This is the question 1. Question 2: min_disk and min_ram - they are allowed to be changed
07:54:04 jm1 ard_: this should fail if we read the api correctly https://review.opendev.org/c/openstack/ansible-collections-openstack/+/862864
07:55:36 jm1 ard_: may i alter your patch?
07:56:43 ard_ jm1: of course you can. I came here to get a working solution at the end.
08:01:32 opendevreview Jakob Meng proposed openstack/ansible-collections-openstack master: Existing images update name, visibility etc https://review.opendev.org/c/openstack/ansible-collections-openstack/+/862565
08:01:55 jm1 ard_: ^ does this answer your question regarding min_disk..? :D
08:06:12 opendevreview Jakob Meng proposed openstack/ansible-collections-openstack master: Existing images update name, visibility etc https://review.opendev.org/c/openstack/ansible-collections-openstack/+/862565
08:06:40 ard_ jm1: yes, this does answer it. I didn't put it in myself, wanted to discuss first as there might been a reason for this. Especially with the kernel parameter present. Also, min_disk has a default value of 0, so you can't just do like you did. It's default value should be moved to _build_params function
08:07:32 ard_ jm1: here https://opendev.org/openstack/ansible-collections-openstack/src/branch/master/plugins/modules/image.py#L460
08:12:55 jm1 ard_: why does min_disk not work?
08:14:51 ard_ if you run update image without this value it will be defaulted to 0 and if image had a limit, it will be reset to 0

Earlier   Later