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

Neutron external connectivity to and from tenant VMs : Help
by KK CHN 16 Mar '24

16 Mar '24

Hi, Neutron external network connection to and from instances.. Problem statement. I have deployed AIO on a Virtual Machine. (Created the demo networks, flavors and images by init-runonce script.) I created a cirros instance with a demo-net instance, and the instance is spawning with 10.0.0.0/24 ips. *inside the cirros Vm I am able to ping its own ip(10.0.0.73) and 10.0.0.1 and the "public1" network gateway 10.176.17.63 .. But unable to ping the Base VM IP 10.176.17.61* Any hints how I can reach the Base VM IP 10.176.17.61 ? from 10.0.0.73 and vice versa .. What steps I missed or I am unaware of? To get the external connection/ping/access..? I have referred many documents and I am at the end of the rope, but couldn't find a solution or what the exact issue is , any guidance much appreciated... Krish. If more information is required : There are two networks by default created 1. public1. with gateway as 10.176.17.63 public1-subnet <http://10.220.0.24/project/networks/subnets/3b9e11ae-4595-4e4c-ba71-1fba209…> 10.176.16.0/23 IPv4 10.176.17.63 2. demo-net demo-subnet <http://10.220.0.24/project/networks/subnets/80e8d33e-6276-450b-bb46-76446dc…> 10.0.0.0/24 IPv4 10.0.0.1 These are the values given in the " kolla_ansible_venv3/share/kolla-ansible/init-runonce" script.. ################################################################################# DEMO_NET_CIDR=${DEMO_NET_CIDR:-'10.0.0.0/24'} DEMO_NET_GATEWAY=${DEMO_NET_GATEWAY:-'10.0.0.1'} DEMO_NET_DNS=${DEMO_NET_DNS:-'8.8.8.8'} ENABLE_EXT_NET=${ENABLE_EXT_NET:-1} EXT_NET_CIDR=${EXT_NET_CIDR:-'10.176.17.0/23'} EXT_NET_RANGE=${EXT_NET_RANGE:-'start=10.176.17.62,end=10.176.17.80'} EXT_NET_GATEWAY=${EXT_NET_GATEWAY:-'10.176.16.1'} ################################################################################ Demo Router: (ee6500a8-039c) <http://10.220.0.24/project/networks/ports/ee6500a8-039c-4ceb-8dc0-b37e2c3a2…> - 10.176.17.63 Active External Gateway UP (bb4c9437-82fa) <http://10.220.0.24/project/networks/ports/bb4c9437-82fa-4689-b125-9edc1987c…> - 10.0.0.1 Active Internal Interface UP (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ grep ^[^#] /etc/kolla/globals.yml --- workaround_ansible_issue_8743: yes config_strategy: "COPY_ALWAYS" kolla_base_distro: "ubuntu" openstack_release: "2023.1" kolla_internal_vip_address: "10.220.0.24" // a free unused IP address in 10.220.0.0/24 segment. kolla_external_vip_address: "{{ kolla_internal_vip_address }}" kolla_container_engine: docker network_interface: "ens224" /// this vNIC is with ip 10.220.0.51 and without internet - a vlan segment for internal experiments. neutron_external_interface: "ens160" // this is the vNIC with my organization dhcp leased ip 10.176.17.61 assigned and up and running neutron_plugin_agent: "openvswitch" nova_compute_virt_type: "qemu" (kolla_ansible_venv3) ubuntu@ub Strange Behaviour: When I create another instance ( Cirros) with the network selected as " public1" network, the instance is spawning the horizon dashboard showing IP as 10.176.17.70 extTestVM <http://10.220.0.24/project/instances/9e744ab1-7a21-4d55-ad03-c01d5631657a/> cirros 10.176.17.70 But inside this VM $ ip a /// lists the IP address of this VM as 169.254.198.1/16 ?? why 169.254 .198.1/16 ? It should be 10.176.17.70 right ?? What's happening ?? Confused ..

3 4

[all][tc][policy] RBAC discussion in 2024.2 PTG
by Ghanshyam Mann 16 Mar '24

16 Mar '24

Hello Everyone, I have booked the Tuesday 15-16 UTC slot Folsom room for the RBAC discussion. Feel free to add the topics/queries to be discussed or your project-related RBAC session info in the below etherpad: - https://etherpad.opendev.org/p/rbac-2024.2-ptg -gmann

1 0

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

15 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 14 Mar '24

14 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