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

Enabling SNAT for Non-Private Addresses
by Jan Wasilewski 16 Mar '24

16 Mar '24

Hi everyone, I'd like to inquire about SNAT settings for non-private addresses. I've created a network with the subnet 100.70.0.0/24 (please note, it starts with 100, not 10). I'm wondering why all hosts attached to such a network cannot establish an internet connection when the network is connected to a router with an external gateway that has internet access. However, I found documentation here: https://docs.openstack.org/neutron/zed/admin/intro-nat.html, which states that SNAT works only for private addresses (so mine are not included). Is there a way to enable SNAT for my subnet as well, but in a different way than manually configuring iptables settings on top of Neutron nodes? If so, could anyone share it? Thanks in advance for your help. /Jan Wasilewski

2 3

[kolla-ansible][Antelope][Heat] Auto Scaling Group - Cancel Update
by Devin Patterson 15 Mar '24

15 Mar '24

Hello, We are working on a workflow to cancel in progress rolling updates for the resource OS::Heat::AutoScalingGroup When we run the command `openstack stack cancel <stack-id> it cancels the Heat stack update, but the Auto-Scaling group finishes updating all VMs in the group. We need a way to either rollback or completely cancel the Auto Scaling Group update and not replace any additional VMs. Any help would be appreciated. Devin

1 0

[release] Release countdown for week R-2
by Thierry Carrez 15 Mar '24

15 Mar '24

Development Focus ----------------- At this point we should have release candidates (RC1 or recent intermediary release) for all the 2024.1 Caracal deliverables. Teams should be working on any release-critical bugs that would require another RC or intermediary release before the final release. Actions ------- Early in the week, the release team will be proposing stable/2024.1 branch creation for all deliverables that have not branched yet, using the latest available 2024.1 Caracal release as the branch point. If your team is ready to go for creating that branch, please let us know by leaving a +1 on these patches. If you would like to wait for another release before branching, you can -1 the patch and update it later in the week with the new release you would like to use. By the end of the week the release team will merge those patches though, unless an exception is granted. Once stable/2024.1 branches are created, if a release-critical bug is detected, you will need to fix the issue in the master branch first, then backport the fix to the stable/2024.1 branch before releasing out of the stable/2024.1 branch. After all of the cycle-with-rc projects have branched we will branch devstack, grenade, and the requirements repos. This will effectively open them up for 2024.2 Dalmatian development, though the focus should still be on finishing up 2024.1 Caracal until the final release. Opening up the new development cycle is also a good opportunity to teams to revise their zuul jobs and used nodesets and clean up all unnecessary ones. For projects with translations, watch for any translation patches coming through and merge them quickly. A new release should be produced so that translations are included in the final 2024.1 Caracal release. Finally, now is a good time to finalize release notes. In particular, consider adding any relevant "prelude" content. Release notes are targeted for the downstream consumers of your project, so it would be great to include any useful information for those that are going to pick up and use or deploy the 2024.1 Caracal version of your project. Upcoming Deadlines & Dates -------------------------- Final RC deadline: March 28th, 2024 (R-1 week) Final 2024.1 Caracal release: April 3rd, 2024 Dalmatian PTG: April 8-12, 2024 -- Thierry Carrez (ttx)

1 0

[skyline] Pending changes to Kolla-ansible for Skyline
by Jäger Uwe 15 Mar '24

15 Mar '24

Dear Skyline-Team, I have created a couple of changes for Kolla-ansible to have Skyline configured to use the latest features. If you find the time, your are invited to have a look at those changes: 909481: Allow overriding of Skyline logos | https://review.opendev.org/c/openstack/kolla-ansible/+/909481 910514: Skyline configure Prometheus | https://review.opendev.org/c/openstack/kolla-ansible/+/910514 905861: Allow customizing of Skyline configuration | https://review.opendev.org/c/openstack/kolla-ansible/+/905861 905860: Update Skyline configuration to enable SSO | https://review.opendev.org/c/openstack/kolla-ansible/+/905860 909329: Fix Skyline API Server TLS configuration | https://review.opendev.org/c/openstack/kolla-ansible/+/909329 909482: Add more services to nginx.conf | https://review.opendev.org/c/openstack/kolla-ansible/+/909482 If you have any questions or comments, please leave them there or contact me directly. Kind regards Uwe

2 1

[dev][ops][neutron] - Securing traffic in colocation env with E2E encryption
by Filip Dobrovolný 15 Mar '24

15 Mar '24

Dear OpenStack Community, I am currently contributing to the Sovereign Cloud Stack (SCS—https://scs.community/) initiative, specifically focusing on enhancing the security of our services through End-to-End (E2E) encryption, particularly in environments where the networking infrastructure isn't directly managed or owned by the OpenStack operator. This scenario is common in colocation settings, Our servers may span multiple racks or buildings that are not entirely under our control. My current focus has been on developing a threat model that addresses potential Man In The Middle (MITM) attacks, such as wiretapping or spoofing, could target physical cables or networking devices. This model is inspired by the security considerations in RFC 8926 I have detailed this model in a GitHub issue: https://github.com/SovereignCloudStack/issues/issues/532#issuecomment-19909… if someone would like to take a deeper look at it and provide feedback. We would greatly value your expertise and feedback on this, either directly on GitHub or via this mailing list. Considering the technical implementation, I'm inclined to employ IPSec, inspired by its usage in TripleO: https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/feature… I'd like to hear your insights, recommendations, or experiences regarding the threat model. Are there other potential threats that should be on our radar? If you're aware of any existing solutions or have faced similar challenges, your guidance would be immensely helpful. Thank you in advance for your valuable contributions. I look forward to your feedback. Best Regards, Filip Dobrovolný

1 0

[cinder] Festival of XS reviews (15 March)
by Rajat Dhasmana 15 Mar '24

15 Mar '24

Hello Argonauts, We will be having our monthly festival of reviews this Friday i.e. 15th March (Friday) from 1400-1600 UTC. This will be the last festival for the 2024.1 Caracal cycle. Following are the details: Date: 15th March, 2024 Time: 1400-1600 UTC Meeting link: https://meet.google.com/jqg-eigw-rku etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews Thanks Rajat Dhasmana

1 0

[tacker] Patches cannot pass zuul check for RC1
by Yasufumi Ogawa 15 Mar '24

15 Mar '24

Hi team, We still have several patches remained for unexpected failures on zuul check tests. All the failures happen in codes other than we updated and are not always happened. It might be the difficulty we usually meet at the end of releases because of lack of resources on the environment. Unfortunately, it's already over the deadline of RC1 although it can be merged if we have enough time to recheck unitll it's passsed. So, I'd like to fix Tacker's Caracal release and propose to backport the remained patches later. Thank you for your contribution. https://review.opendev.org/c/openstack/tacker/+/908878 https://review.opendev.org/c/openstack/tacker/+/910504 https://review.opendev.org/c/openstack/tacker/+/911639 https://review.opendev.org/c/openstack/tacker/+/907022 https://review.opendev.org/c/openstack/tacker/+/907025 https://review.opendev.org/c/openstack/tacker/+/908752 https://review.opendev.org/c/openstack/tacker/+/907026 https://review.opendev.org/c/openstack/tacker/+/907694 Regards, Yasufumi

1 0

OSSN-0093: Unresolved Vulnerability in OpenStack Murano
by Jeremy Stanley 15 Mar '24

15 Mar '24

OSSN-0093 Unresolved Vulnerability in OpenStack Murano ### Summary ### A severe security vulnerability in all versions of the Murano service will be disclosed at a later date. Murano is an inactive project[*], so no fix is currently under development for this vulnerability. It is strongly recommended that any OpenStack deployments disable or fully remove Murano, if installed, at the earliest opportunity. This security note will be amended at the time of public disclosure to include further details and context, but action should be taken as soon as possible in order to minimize the risk it poses. [*] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… ### Affected Services / Software ### - murano: all versions ### Discussion ### This security note is a redacted placeholder, and will be amended with complete details once the associated bug report becomes public. ### Recommended Actions ### Disable the Murano service in, or fully remove it from, all OpenStack deployments at the earliest opportunity. ### Credits ### Not yet disclosed. ### Contacts / References ### Authors: - Jeremy Stanley, OpenStack Vulnerability Coordinator This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0093 Original bug: https://launchpad.net/bugs/2048114 (not yet public) Mailing List : [security-sig] openstack-discuss(a)lists.openstack.org -- Jeremy Stanley, OpenStack Vulnerability Coordinator

1 1

[requirements][releases][heat][mistral][murano] Requirements freeze exception for yaql
by Takashi Kajinami 15 Mar '24

15 Mar '24

Hello, I have another exception request... A critical security issue[1] was discovered recently and we are updating yaql to fix the issue. The required change was already merged into yaql and I've proposed a new yaql release[2]. I'd like to request a requirement freeze exception to pull the fixed version into upper constraints for 2024.1. Please let me know if you have any concern. Thank you, Takashi [1] https://bugs.launchpad.net/yaql/+bug/2048114 [2] https://review.opendev.org/c/openstack/releases/+/913230 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

3 2

[nova][placement] Zombie placement allocations DB records
by hai wu 14 Mar '24

14 Mar '24

Sometimes there are zombie placement allocations records left for hypervisors, meaning there are no mapping VMs running on those hosts, but the placement allocation records still show up in the database. Does this mean that nova conductor/scheduler would still think those resources have already been allocated, while in reality, there's no existing VMs mapped to those zombie placement allocations records?

3 3