March 2024 - openstack-discuss - lists.openstack.org

Re: [keystone] application creds issue with permission
by Satish Patel 13 Mar '24

13 Mar '24

Hi Artem, You are 100% correct here, I have noticed as soon as I give the reader the role it works. Thank you! On Tue, Mar 12, 2024 at 4:02 PM Artem Goncharov <artem.goncharov(a)gmail.com> wrote: > Can you please check which roles are bound to the appcred? The reason I am > asking is https://review.opendev.org/c/openstack/keystone/+/910337 (wrong > treatment of implied roles when you create appcred explicitly specifying > role that implies another role (basically if you create appcred with member > role - reader role is not given) > > ---- > typed from mobile, auto-correct typos assumed > ---- > > On Tue, Mar 12, 2024, 20:57 Satish Patel <satish.txt(a)gmail.com> wrote: > >> Folks, >> >> I am running the 2023.1 release of openstack using kolla-ansible. I have >> integrated with LDAP and everything works fine. But today when I created >> application creds and used that to access openstack api I got all kinds of >> strange auth errors. >> >> #!/usr/bin/env bash >> export OS_AUTH_TYPE=v3applicationcredential >> export OS_AUTH_URL=https://openstack-eng.example.com:5000 >> export OS_IDENTITY_API_VERSION=3 >> export OS_REGION_NAME="eng" >> export OS_INTERFACE=public >> export OS_APPLICATION_CREDENTIAL_ID=ee17300916b1401f912f6140ce9cd642 >> export OS_APPLICATION_CREDENTIAL_SECRET=XXXXXXXXX >> >> # openstack server list >> ForbiddenException: 403: Client Error for url: >> https://openstack-eng.example.com:8774/v2.1/servers/detail?deleted=False, >> Policy doesn't allow os_compute_api:servers:detail to be performed. >> >> >> # openstack image list >> ForbiddenException: 403: Client Error for url: >> https://openstack-eng.example.com:9292/v2/images, You are not authorized >> to complete get_images action.<br /><br /> >> >> What is wrong here because I have one more setup of openstack which is >> not using LDAP but in that cloud application creds working fine. >> >> # cat /etc/keystone/keystone.conf >> >> [DEFAULT] >> debug = False >> transport_url = hiding.... >> log_file = /var/log/kolla/keystone/keystone.log >> use_stderr = True >> >> [oslo_middleware] >> enable_proxy_headers_parsing = True >> >> [database] >> connection = mysql+pymysql:// >> keystone:hiding...@openstack-eng.example.com:3306/keystone >> connection_recycle_time = 10 >> max_pool_size = 1 >> max_retries = -1 >> >> [identity] >> domain_specific_drivers_enabled = true >> domain_config_dir = /etc/keystone/domains >> >> [token] >> revoke_by_id = False >> provider = fernet >> expiration = 86400 >> allow_expired_window = 172800 >> >> [fernet_tokens] >> max_active_keys = 3 >> >> [cache] >> backend = oslo_cache.memcache_pool >> enabled = True >> memcache_servers = 10.0.25.201:11211,10.0.25.202:11211,10.0.25.203:11211 >> >> [oslo_messaging_notifications] >> transport_url = rabbit://openstack:hiding.... >> driver = noop >> >> [oslo_messaging_rabbit] >> heartbeat_in_pthread = True >> amqp_durable_queues = true >> rabbit_quorum_queue = true >> kombu_reconnect_delay = 0.5 >> rabbit_transient_queues_ttl = 60 >> >> >> # cat /etc/keystone/domains/keystone.eng.conf >> >> # Ansible managed >> >> [identity] >> driver = ldap >> >> [ldap] >> debug_level = 4095 >> group_allow_create = False >> group_allow_delete = False >> group_allow_update = False >> group_id_attribute = cn >> hiding.... >> hiding.... >> >>

1 0

[keystone] application creds issue with permission
by Satish Patel 13 Mar '24

13 Mar '24

Folks, I am running the 2023.1 release of openstack using kolla-ansible. I have integrated with LDAP and everything works fine. But today when I created application creds and used that to access openstack api I got all kinds of strange auth errors. #!/usr/bin/env bash export OS_AUTH_TYPE=v3applicationcredential export OS_AUTH_URL=https://openstack-eng.example.com:5000 export OS_IDENTITY_API_VERSION=3 export OS_REGION_NAME="eng" export OS_INTERFACE=public export OS_APPLICATION_CREDENTIAL_ID=ee17300916b1401f912f6140ce9cd642 export OS_APPLICATION_CREDENTIAL_SECRET=XXXXXXXXX # openstack server list ForbiddenException: 403: Client Error for url: https://openstack-eng.example.com:8774/v2.1/servers/detail?deleted=False, Policy doesn't allow os_compute_api:servers:detail to be performed. # openstack image list ForbiddenException: 403: Client Error for url: https://openstack-eng.example.com:9292/v2/images, You are not authorized to complete get_images action.<br /><br /> What is wrong here because I have one more setup of openstack which is not using LDAP but in that cloud application creds working fine. # cat /etc/keystone/keystone.conf [DEFAULT] debug = False transport_url = hiding.... log_file = /var/log/kolla/keystone/keystone.log use_stderr = True [oslo_middleware] enable_proxy_headers_parsing = True [database] connection = mysql+pymysql:// keystone:hiding...@openstack-eng.example.com:3306/keystone connection_recycle_time = 10 max_pool_size = 1 max_retries = -1 [identity] domain_specific_drivers_enabled = true domain_config_dir = /etc/keystone/domains [token] revoke_by_id = False provider = fernet expiration = 86400 allow_expired_window = 172800 [fernet_tokens] max_active_keys = 3 [cache] backend = oslo_cache.memcache_pool enabled = True memcache_servers = 10.0.25.201:11211,10.0.25.202:11211,10.0.25.203:11211 [oslo_messaging_notifications] transport_url = rabbit://openstack:hiding.... driver = noop [oslo_messaging_rabbit] heartbeat_in_pthread = True amqp_durable_queues = true rabbit_quorum_queue = true kombu_reconnect_delay = 0.5 rabbit_transient_queues_ttl = 60 # cat /etc/keystone/domains/keystone.eng.conf # Ansible managed [identity] driver = ldap [ldap] debug_level = 4095 group_allow_create = False group_allow_delete = False group_allow_update = False group_id_attribute = cn hiding.... hiding....

1 0

[ansible][aio][glance] Cannot create image, TypeError: Response is undefined
by Tang Chai Keong 12 Mar '24

12 Mar '24

I deployed openstack-ansible AIO and is trying to create a new image but is encountering "TypeError: Response is undefined" and "Error: Unable to create the image". The image creation task is just stuck in the "queued" mode forever after that. I also do not see any of the service logs in the lxc containers under /var/logs/ folder. Appreciate any advice on how I can troubleshoot this. Thank you. Regards, Ben

2 2

[tc] Next Meeting Tomorrow, March 12, 1800 UTC
by Jay Faulkner 12 Mar '24

12 Mar '24

Hi all, the next weekly meeting of the OpenStack Technical Committee is tomorrow, March 12, at 1800 UTC. It will be held on #openstack-tc in OFTC. *US-based contributors please note that the meeting time does not change with DST.* The proposed agenda is: - Roll call - Follow up on tracked action items - Gate health check - Implementation of Unmaintained branch statuses - Testing runtime for 2024.2 release (gmann) - https://review.opendev.org/c/openstack/governance/+/908862 - TC vPTG 2024.2 / TC Tracker 2024.1 - https://etherpad.opendev.org/p/tc-2024.1-tracker - https://etherpad.opendev.org/p/apr2024-ptg-os-tc - Open Discussion and Reviews Thanks, Jay Faulkner OpenStack TC Chair

1 0

[swift][s3api] put-object-acl in SLO objects
by Thiago De Moraes Teixeira 12 Mar '24

12 Mar '24

Hi, I've got this error when trying to put acl in objects that are a multipart upload with s3api client. *aws s3api put-object-acl --bucket ramac --key darwin --acl public-readAn error occurred (BadDigest) when calling the PutObjectAcl operation (reached max retries: 4): The Content-MD5 you specified did not match what we received.* And for objects greater than 5Gb the error is: *An error occurred (EntityTooLarge) when calling the PutObjectAcl operation: Your proposed upload exceeds the maximum allowed object size.* I noticed this is happening because s3 middleware did not recognize this object as an SLO, so when the request reaches the ServerSideCopyMiddleware, the request did not have the query param "multipart-manifest". I tried this swift patch, to solve this problem, identifying if the object is an SLO, on head object in acl_handlers.py class, and retrieving this information before request transformation to swift_request, adding the query param. While this patch resolves the immediate issue, I believe there's room for improvement. I welcome any suggestions or feedback on enhancing this patch further. Your insights would be greatly appreciated. https://paste.openstack.org/show/bd2nAHIHPtUtDNbWLorD/ Best regards -- _‘Esta mensagem é direcionada apenas para os endereços constantes no cabeçalho inicial. Se você não está listado nos endereços constantes no cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão imediatamente anuladas e proibidas’._ * **‘Apesar do Magazine Luiza tomar todas as precauções razoáveis para assegurar que nenhum vírus esteja presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*

1 0

[swift][middleware][s3] Content-type of s3api versioning response
by m.victorello＠luizalabs.com 12 Mar '24

12 Mar '24

Hello, We are having some compatibility problems caused by the lack of content-type in this part: https://github.com/openstack/swift/blob/5e5fde12400fc76b9df43b3fcd13eb8a226… def GET(self, req): """ Handles GET Bucket versioning. """ sysmeta = req.get_container_info(self.app).get('sysmeta', {}) elem = Element('VersioningConfiguration') if sysmeta.get('versions-enabled'): SubElement(elem, 'Status').text = ( 'Enabled' if config_true_value(sysmeta['versions-enabled']) else 'Suspended') body = tostring(elem) return HTTPOk(body=body, content_type=None) Is there a reason for it?

1 0

[swift][s3][multipart] S3 multipart re-upload leaves orphan segments
by m.victorello＠luizalabs.com 12 Mar '24

12 Mar '24

Hello, I understand that this is a known issue for some time, but I dont know if it has been resolved. As far as I know stable/2023.2 still has this problem, is there any related work? We think there are two fronts: - Segments of incomplete multipart, forgotten by the user - Completed re-uploads We plan to fix those: - Using the object-expirer in a new middleware - Deploying workers to review all files, checking if they are still in use What are your thoughts?

1 0

[kolla-ansible] Building images from source
by wodel youchi 11 Mar '24

11 Mar '24

Hi, I am trying to build kolla's container images from source, especially octavia's images. I've read the kolla-build documentation, then I tried to follow along but I am having some problems. I am not a developper, my goal is to be able to push patches to kolla images if something goes wrong. For example now I am having a problem with octavia not being able to create an LB when using a self-signed certificate. I searched and I found a patch and I wanted to test-it. https://bugs.launchpad.net/kolla-ansible/+bug/2046382 https://launchpadlibrarian.net/706867161/octavia.patch Here are the steps I followed : - I am using podman - I've created a local registry - pyhton3.9 -m venv kollavnenv/2023.2 - source kollavnenv/2023.2/bin/activate - pip install kolla - pip install podman - I downloaded octavia source code from git 2023.2 version - https://github.com/openstack/octavia/tree/stable/2023.2 - I've prepared kolla_build.conf like this - [octavia] type = local location = /root/work/octavia - And I started the build like this - kolla-build --registry 192.168.2.35:4000 --push -b rocky --tag 2023.2-1 --engine podman --config-file ./kolla_build.conf octavia - Results - (2023.2) [root@r9localrepo work]# podman images REPOSITORY TAG IMAGE ID CREATED SIZE 192.168.2.35:4000/kolla/octavia-driver-agent 2023.2-1 1a6217ad71b4 22 minutes ago 1.31 GB 192.168.2.35:4000/kolla/octavia-api 2023.2-1 41ad8e1760a2 22 minutes ago 1.31 GB 192.168.2.35:4000/kolla/octavia-health-manager 2023.2-1 4922b7f0259f 22 minutes ago 1.28 GB 192.168.2.35:4000/kolla/octavia-housekeeping 2023.2-1 8b5a4785fc18 22 minutes ago 1.28 GB 192.168.2.35:4000/kolla/octavia-worker 2023.2-1 46107a14e78d 22 minutes ago 1.28 GB 192.168.2.35:4000/kolla/octavia-base 2023.2-1 23963c04eda7 22 minutes ago 1.28 GB 192.168.2.35:4000/kolla/openstack-base 2023.2-1 add627cfde2f 25 minutes ago 1.14 GB 192.168.2.35:4000/kolla/base 2023.2-1 a8299a02411a 29 minutes ago 580 MB <none> <none> 0421c38fd25c 8 hours ago 1.14 GB docker.io/library/registry 2 a8781fe3b7a2 6 weeks ago 26 MB quay.io/rockylinux/rockylinux 9 da830f5e2510 3 months ago 181 MB - The problem : - When exploring the octavia-api images for example (podman save),* and verifying the modified file I didn't find the patched-code* It seems that the build process is not using the local code? What am I missing? I think that my kolla_build.conf is wrong or not complete ... any ideas? Regards.

1 2

[kolla-ansible][2023.2] Cloudkitty support for Openseach?
by wodel youchi 11 Mar '24

11 Mar '24

Hi, Does Cloudkitty now support Opensearch as a storage backend in kolla? Regards.

2 1

[oslo][release][requirements] RFE for tooz and taskflow
by Takashi Kajinami 11 Mar '24

11 Mar '24

Hello, During this cycle we updated the redis support implementations to support authentication and SSL for redis sentinel, following the new implementation in oslo.cache. However later it turned out this change breaks kolla because it has been using redis sentinel without authentication while it enables authentication in redis[1]. I've submitted the changes[2] to restore the old behavior (not to enable AUTH or SSL for sentinel even when one is enabled in redis). Once these are merged in master then I'll propose backports to stable/2024.1 and propose new stable/2024.1 release. I'd like to request approval about the release and also bumping tooz and taksflow version in stable/2024.1 requirements to unblock kolla and any other deployments using the partial authentication for redis sentinel. Thank you, Takashi [1] https://bugs.launchpad.net/python-tooz/+bug/2056656 [2] https://review.opendev.org/c/openstack/taskflow/+/912346 https://review.opendev.org/c/openstack/tooz/+/912344/ -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

3 3