March 2023 - openstack-discuss - lists.openstack.org

[neutron][ovn] stateless SG behavior for metadata / slaac / dhcpv6
by Ihar Hrachyshka 30 Mar '23

30 Mar '23

Hi all, (I've tagged the thread with [ovn] because this question was raised in the context of OVN, but it really is about the intent of neutron stateless SG API.) Neutron API supports 'stateless' field for security groups: https://docs.openstack.org/api-ref/network/v2/index.html#stateful-security-… The API reference doesn't explain the intent of the API, merely walking through the field mechanics, as in "The stateful security group extension (stateful-security-group) adds the stateful field to security groups, allowing users to configure stateful or stateless security groups for ports. The existing security groups will all be considered as stateful. Update of the stateful attribute is allowed when there is no port associated with the security group." The meaning of the API is left for users to deduce. It's customary understood as something like "allowing to bypass connection tracking in the firewall, potentially providing performance and simplicity benefits" (while imposing additional complexity onto rule definitions - the user now has to explicitly define rules for both directions of a duplex connection.) [This is not an official definition, nor it's quoted from a respected source, please don't criticize it. I don't think this is an important point here.] Either way, the definition doesn't explain what should happen with basic network services that a user of Neutron SG API is used to rely on. Specifically, what happens for a port related to a stateless SG when it trying to fetch metadata from 169.254.169.254 (or its IPv6 equivalent), or what happens when it attempts to use SLAAC / DHCPv6 procedure to configure its IPv6 stack. As part of our testing of stateless SG implementation for OVN backend, we've noticed that VMs fail to configure via metadata, or use SLAAC to configure IPv6. metadata: https://bugs.launchpad.net/neutron/+bug/2009053 slaac: https://bugs.launchpad.net/neutron/+bug/2006949 We've noticed that adding explicit SG rules to allow 'returning' communication for 169.254.169.254:80 and RA / NA fixes the problem. I figured that these services are "base" / "basic" and should be provided to ports regardless of the stateful-ness of SG. I proposed patches for this here: metadata series: https://review.opendev.org/q/topic:bug%252F2009053 RA / NA: https://review.opendev.org/c/openstack/neutron/+/877049 Discussion in the patch that adjusts the existing stateless SG test scenarios to not create explicit SG rules for metadata and ICMP replies suggests that it's not a given / common understanding that these "base" services should work by default for stateless SGs. See discussion in comments here: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/876692 While this discussion is happening in the context of OVN, I think it should be resolved in a broader context. Specifically, a decision should be made about what Neutron API "means" by stateless SGs, and how "base" services are supposed to behave. Then backends can act accordingly. There's also an open question of how this should be implemented. Whether Neutron would like to create explicit SG rules visible in API that would allow for the returning traffic and that could be deleted as needed, or whether backends should do it implicitly. We already have "default" egress rules, so there's a precedent here. On the other hand, the egress rules are broad (allowing everything) and there's more rationale to delete them and replace them with tighter filters. In my OVN series, I implement ACLs directly in OVN database, without creating SG rules in Neutron API. So, questions for the community to clarify: - whether Neutron API should define behavior of stateless SGs in general, - if so, whether Neutron API should also define behavior of stateless SGs in terms of "base" services like metadata and DHCP, - if so, whether backends should implement the necessary filters themselves, or Neutron will create default SG rules itself. I hope I laid the problem out clearly, let me know if anything needs clarification or explanation. Yours, Ihar

3 6

[Magnum] vPTG
by Jake Yip 30 Mar '23

30 Mar '23

Dear all, Magnum vPTG will be held at Wed 0900 UTC in the Havana Room. Please see etherpad https://etherpad.opendev.org/p/march2023-ptg-magnum for updates Regards, Jake (sorry for duplicates)

1 1

OpenStack 2023.1 Antelope for Ubuntu 22.04 LTS
by Corey Bryant 30 Mar '23

30 Mar '23

The Ubuntu OpenStack team at Canonical is pleased to announce the general availability of OpenStack 2023.1 Antelope on Ubuntu 22.04 LTS (Jammy Jellyfish). Details of the Antelope release can be found at: https://www.openstack.org/software/antelope The Ubuntu Cloud Archive for OpenStack 2023.1 Antelope can be enabled on Ubuntu 22.04 by running the following command: sudo add-apt-repository cloud-archive:antelope The Ubuntu Cloud Archive for 2023.1 Antelope includes updates for: aodh, barbican, ceilometer, cinder, designate, designate-dashboard, dpdk (22.11.1), glance, gnocchi, heat, heat-dashboard, horizon, ironic, ironic-ui, keystone, magnum, magnum-ui, manila, manila-ui, masakari, mistral, murano, murano-dashboard, networking-arista, networking-bagpipe, networking-baremetal, networking-bgpvpn, networking-hyperv, networking-l2gw, networking-mlnx, networking-odl, networking-sfc, neutron, neutron-dynamic-routing, neutron-fwaas, neutron-taas, neutron-vpnaas, nova, octavia, octavia-dashboard, openstack-trove, openvswitch (3.1.0), ovn (23.03.0), ovn-octavia-provider, placement, sahara, sahara-dashboard, senlin, swift, trove-dashboard, vitrage, watcher, watcher-dashboard, zaqar, and zaqar-ui. For a full list of packages and versions, please refer to: https://openstack-ci-reports.ubuntu.com/reports/cloud-archive/antelope_vers… == Reporting bugs == If you have any issues please report bugs using the ‘ubuntu-bug’ tool to ensure that bugs get logged in the right place in Launchpad: sudo ubuntu-bug nova-conductor Thank you to everyone who contributed to OpenStack 2023.1 Antelope! Corey (on behalf of the Ubuntu OpenStack Engineering team)

1 0

(Openstack-Designate) rndc key not getting generated in /etc/designate
by Adivya Singh 30 Mar '23

30 Mar '23

Hi Team, My DNS Server located outside the Open Stack, and i am using below variables in my user_variables.yaml File. But When i ' m running os-desigante-install.yml Playbook, rndc key are not generating in /etc/designate Folder and the playbook fail at the below Task {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'file'\n\nThe error appears to be in '/etc/ansible/roles/os_designate/tasks/designate_post_install.yml': line 89, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Create Designate rndc key file\n ^ here\n"} - name: Create Designate rndc key file template: src: rndc.key.j2 dest: "{{ item.file }}" owner: "{{ item.owner | default('root') }}" group: "{{ item.group | default('root') }}" mode: "{{ item.mode | default('0600') }}" with_items: "{{ designate_rndc_keys }}" when: designate_rndc_keys is defined and the post-install.yml File looks like this Any idea on this, Where i am missing ## rndc keys for authenticating with bind9 # define this to create as many key files as are required # designate_rndc_keys # - name: "rndc-key" # file: /etc/designate/rndc.key # algorithm: "hmac-md5" # secret: "<key>"

2 1

[ironic] bug tracking move to launchpad
by Julia Kreger 30 Mar '23

30 Mar '23

Greetings Ironic! During the PTG yesterday, we discussed the fact we had not moved back to Launchpad for bug tracking. Mainly because we are all very busy. The point was raised, why don't we just re-enable launchpad bug tracking, and move our primary usage back to that. Consensus on the call resulted with this proposal, and the consensus to send this email to the mailing list. As such, if nobody objects, I'm going to go turn the bug tracker for Ironic in launchpad back on next Monday. If you object, scream now and/or write a migration script and/or propose another solution. Thanks! -Julia

1 0

(Openstack-Nova)
by Adivya Singh 30 Mar '23

30 Mar '23

Hi Team I see these error in my syslog related to my nova compute service getting hung while communicating to rabbit-mq service "A recoverable connection/channel error occurred, trying to reconnect: [Errno 24] Too many open files" Is this a OS related error, or some thing i can change to get rid of this error Regards Adivya Singh

3 2

[neutron] BGP for self-service network
by Deniz AYDIN 30 Mar '23

30 Mar '23

Hi, I am looking for options for removing Layer-2 in the underlay as much as possible. The features explained in the document, BGP floating IPs over L2 segmented network <https://docs.openstack.org/neutron/zed/admin/config-bgp-floating-ip-over-l2…>, solve the problem for floating IPS where layer 2 is only needed between servers and rack switches. Is there any specific reason that this feature is limited to floating IPS? As long as we have unique BGP next-hops defined for every DVR, it can also be used for advertising self-service networks /32 routes. Thanks for the help Deniz

1 0

[nova] openstack-tox-pep8 job broken, hold your rechecks
by melanie witt 29 Mar '23

29 Mar '23

Hey all, Sending this to the ML to try to help others who may not have heard about it yet. I didn't know about myself until I saw the job fail on a random nova patch and I looked around to figure out why. It looks like openstack-tox-pep8 is failing 100% in nova due to a newer version of the mypy library being pulled in since a recent upper-constraints bump: https://review.opendev.org/c/openstack/requirements/+/872065 And the job isn't going to pass until the following fix merges: https://review.opendev.org/c/openstack/nova/+/878693 Finally, to help prevent a breakage for this in the future, a cross-nova-pep8 job has been approved: https://review.opendev.org/c/openstack/requirements/+/878748 and will be on its way to the gate once the aforementioned fix merges. I'll post a reply to this email when it's OK to do rechecks again. Cheers, -melwitt

2 3

[nova] Hold your rechecks
by Sylvain Bauza 29 Mar '23

29 Mar '23

Hey, Due to the recent merge of https://review.opendev.org/c/openstack/requirements/+/872065/10/upper-const… we now use mypy==1.1.1 which includes a breaking behavioural change against our code : https://07de6a0c9e6ec0c6835f-ccccbfab26b1456f69293167016566bc.ssl.cf2.rackc… Thanks to Eric (kudos to him, he was quickier than me), we have a fix https://review.opendev.org/c/openstack/nova/+/878693 Please accordingly hold your rechecks until that fix is merged. -Sylvain

1 1

[PTL][release][stable][EM] Extended Maintenance - Xena
by Elõd Illés 29 Mar '23

29 Mar '23

Hi teams, As 2023.1 Antelope was released last week and we are in a less busy period, now is the good time to call your attention to the following: In less than a month Xena is planned to transition to Extended Maintenance phase [1] (planned date: 2023-04-20). I have generated the list of the current *open* and *unreleased* changes in stable/xena for every repositories [2] (where there are such patches). These lists could help the teams who are planning to do a *final* release on Xena before moving stable/xena branches to Extended Maintenance. Feel free to edit and extend these lists to track your team's progress! Note that the *latest* Xena *release* tagging patches ('xena-em' tag) have been generated too in advance [3], please mark with a -1 if your team plans to do a final release, or +1 if the team is ready for the transition. The schedule from now on is as follows: * patches with +1 from PTL / release liaison will be merged, thus those repositories will transition to Extended Maintenance * at the planned deadline (April 20th) the Release Team will merge all of the transition patches (even the ones without any response!) * after the transition, stable/xena will be still open for bug fixes, but there won't be official releases anymore. *NOTE*: teams, please focus on wrapping up your libraries first if there is any concern about the changes, in order to avoid broken (final!!) releases! [1] https://releases.openstack.org/ [2] https://etherpad.opendev.org/p/xena-final-release-before-em [3] https://review.opendev.org/q/topic:xena-em Thanks, Előd irc: elodilles @ #openstack-release

1 0