June 2024 - openstack-discuss - lists.openstack.org

oslopolicy-policy-generator: what is the namespace to use to get Mgnum policy?
by Michel Jouvin 07 Jun '24

07 Jun '24

Hi, I'd like to see the default Magnum (Oslo) policy used with Magnum. With other services, I use oslopolicy-policy-generator and use the service name as the namespace but for Magnum, "--namespace magnum" returns an error saying that there is no "magnum" namespace. Does anybody know what is the namespace to use with Magnum? Or how to display the currently active policy, preferably in YAML format? Thanks in advance. Cheers, Michel

2 6

[swift] clean up orphan segment parts
by Rafael Tavares Oliveira 07 Jun '24

07 Jun '24

Hey there! We've been using swift and we came across this bug https://bugs.launchpad.net/swift/+bug/1813202. We decided to work it out and have an ongoing patch to solve this issue alongside ronaldo.maia(a)luizalabs.com, we would like to share and get some feedback before we submit it. To solve this, we took inspiration in obj/expirer.py: In S3 controllers we register task objects in an internal account, each task object points to an orphaned slo object, which can be created in two situations, when a multipart-upload is not completed or when a multipart object is overwritten. These tasks will be checked by the daemon (a new one we made called "s3-slo-expirer") after some time and deleted from the base accounts. Rafael

2 2

[all][tc] Eventlet migration: Call to action
by Jay Faulkner 07 Jun '24

07 Jun '24

Hi all, As you may have read in Goutham's TC summary, the existing eventlet goal[0] is unlikely to gain consensus to merge. This appears to be due to the difference in needs between OpenStack projects, and belief that it's unlikely a single solution would serve them all. Our current situation is: 1) Eventlet usage must be discontinued. The temporary maintainers are just that -- temporary -- and we should not expect eventlet to continue to be a valid path moving forward. 2) We have basic agreement that shared tooling, such as oslo libraries, should not dictate a specific threading model. In lieu of specific technical leadership and guidance from the TC, this leaves it to individual projects to decide what threading model to use instead of eventlet monkey patching. The unmerged spec[0] may be a good starting point if you're wondering where to start. Importantly: do not let this work wait! It is a significant change and will take a long time to complete. Thanks, Jay Faulkner 0: https://review.opendev.org/c/openstack/governance/+/902585

6 7

[neutron] Drivers meeting cancelled tomorrow
by Brian Haley 07 Jun '24

07 Jun '24

Hello Neutrinos: Due to the lack of agenda, Friday's drivers meeting is cancelled. Have a nice weekend! -Brian

1 0

[ironic] Failed when writing image to the device file /dev/sda
by James Leong 06 Jun '24

06 Jun '24

Hi all, I have been exploring ironic, with a simple setup. However, I get the following error messages whenever I attempt to deploy an ISO image to my baremetal node. 1. An agent token generation request is being refused as one is already present for the node 2. Writing image to device /dev/sda failed with exit code 32. stdout: . stderr: lsblk: /dev/sda2: not a block device 3. Invalid or missing agent_token received for node I am not quite sure what is required to be set on my node's property other than vendor and cpu_arch. Any help would be appreciated. Best, James

1 0

[kolla-ansible][Antelope][Keystone] Redelegation Not Working with Heat
by Devin Patterson 06 Jun '24

06 Jun '24

Hello! We are attempting to use role redelegation with Heat and Keystone to deploy a stack that deploys Zaqar subscriptions among other resources. When attempting to scale up the stack, we receive this error: TypeError: '<' not supported between instances of 'NoneType' and 'int') This appears to be sourced from this check in the code in the Keystone core.py file. # expiry times trust_expiry = trust.get('expires_at') redelegated_expiry = redelegated_trust['expires_at'] if trust_expiry: # redelegated trust is from backend and has no tzinfo if redelegated_expiry < trust_expiry.replace(tzinfo=None): raise exception.Forbidden( _('Requested expiration time is more ' 'than redelegated trust can provide')) The issue appears to be related to 'None' values for what is passed into 'expires_at' for 'redelegated_expiry'. We have this config in keystone.conf: [trust] allow_redelegation = True And this in heat.conf: reauthentication_auth_method = trusts allow_trusts_redelegation = True This is how we are scaling the stack: openstack stack resource signal <stack_name> scale_up_policy Any suggestions on how to fix this issue? Thanks, Devin

1 0

[masakari] DB migration failure during upgrade to 2024.1
by Dmitriy Rabotyagov 06 Jun '24

06 Jun '24

Hey folks, Just wanted to let you know, that upgrade of Masakari to 2024.1 is most likely borked due to issue in Alembic migration, where masakari considers taskflow DB as its own, as masakari-manage does not pass correct namespace for alembic. Upgrade path is not tested in CI, which made it possible to slip the issue from the radar. There's a patch existing [1] that fixes the root cause of the issue, though needs to be reviewed and backported. Thus, I wanted to call out Masakari Maintainers for some attention to this issue as well as give operators some awareness about the issue. [1] https://review.opendev.org/c/openstack/masakari/+/920034

1 0

[stackalytics] no "neutron" module for Commits
by Ihar Hrachyshka 06 Jun '24

06 Jun '24

Hi, I noticed that "neutron" is not an option in the Module list when Commits are selected, and no neutron commits are registered since ~Oct 2023. On the other hand, other Neutron program repos (e.g. neutron-lib and neutron-tempest-plugin) are available in the list and do register commits. Also, when Reviews are selected, neutron module is back as an option, and review stats are correctly updated. I checked governance yaml and it doesn't strike me as incorrect: https://opendev.org/openstack/governance/src/commit/5f93b99a3c90b452f6c7368… Any ideas what may have happened? Thanks, Ihar

4 7

[Horizon][Keystone] Multiple OIDC Providers and token deletion at logout
by MIchele Delli Veneri 06 Jun '24

06 Jun '24

Hi, We have configured our keystone and Horizon to work with multiple OIDC Providers and through API I can successfully authenticate with the two providers. When I authenticate through the Horizon dashboard, I can successfully authenticate with both providers if I use two separate browser sessions, If I use the same browser session, I log in with one provider, log out, and then log in with the other, given that the user token is stored, I get an authentication error. The reason for the error is that the token was issued by the first provider and thus it is not accepted as a valid by the second. Is it possible to configure Horizon to revoke/delete a user token at logout or provide session isolation without changes on the provider side? Thank you and best regards, Michele Delli Veneri

1 0

[Horizon][Keystone] Multiple OIDC Providers and token deletion at logout
by Michele Delli Veneri 06 Jun '24

06 Jun '24

Hi, We have configured our keystone and Horizon to work with multiple OIDC Providers and through API I can successfully authenticate with the two providers. When I authenticate through the Horizon dashboard, I can successfully authenticate with both providers if I use two separate browser sessions, If I use the same browser session, I log in with one provider, log out, and then log in with the other, given that the user token is stored, I get an authentication error. The reason for the error is that the token was issued by the first provider and thus it is not accepted as a valid by the second. Is it possible to configure Horizon to revoke/delete a user token at logout or provide session isolation without changes on the provider side? Thank you and best regards, Michele Delli Veneri

1 0