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

[kolla-ansible] deploy cinder and glance with multi-backend
by wodel youchi 30 Mar '23

30 Mar '23

Hi, I need to deploy cinder and glance with multi-backend. My experience for now is simple, my deployment is an HCI built on top of ceph storage, and I am using it to store both cinder volumes and glance images. I have some questions if you can help: - can multi-backend be deployed at first run with kolla-ansible, or do I need to do at least two runs? - reading the doc about multi-backend, I saw that the first backend is specified, do I need to remove the creation of the first backend from glabals.yml and put it in a configuration file cinder.conf and glance.conf? In other words, do I have to create all the backends from the config files, or can I still create the first one using globals.yml and the rest from the config files? I hope my question is clear. Regards.

1 0

[neutron][ptg] Today's agenda
by Rodolfo Alonso Hernandez 30 Mar '23

30 Mar '23

Hello Neutrinos: Same as yesterday, we have a packed agenda. Today we'll have the Nova-Neutron meetings, starting at 13UTC. Quick summary: * delete_on_termination for Neutron ports * Blueprint: "Add support for Napatech LinkVirt SmartNICs" * https://bugs.launchpad.net/neutron/+bug/1986003 * ovn-bgp-agent roadmap * neutron-dynamic-routing: Make static scheduler finally the default? See you in a few minutes. Regards.

1 0

[nova][ptg] Today's agenda (Thursday)
by Sylvain Bauza 30 Mar '23

30 Mar '23

Heya again, Yesterday was a very productive day. Thanks folks. Today, we'll have mostly cross-project discussions but we'll also try to discuss about 3 topics : - 13:00 - 14:30 UTC : Nova-Neutron cross-project sessions* in the neutron room (tbd)* - 14:30 - 14:45 UTC : Transition Xena to EM, any concerns ? - 14:45 - 15:00 UTC : break - 15:00 - 15:30 UTC : Glance/Cinder/Nova cross-project session about secure glance Direct URLs *in the glance room (newton)* - 15:30 - 16:30 UTC : Cinder/Nova cross-project session* in the nova room (diablo)* - 16:30 - 16:50 UTC : Discuss the next steps with compute hostname robustification - 16:50 - 16:00 UTC : (tentatively) Instance.name is not persisted and just sub'd by every service calling the object Thanks and enjoy this day. -Sylvain

1 1

Nova undefine secret | openstack | wallaby
by Swogat Pradhan 30 Mar '23

30 Mar '23

Hi, For some reason, i had to redeploy ceph for my hci nodes and then found that the deployment command is giving out the following error: 2023-03-28 01:49:46.709605 | | WARNING | ERROR: Can't run container nova_libvirt_init_secret stderr: error: Failed to set attributes from /etc/nova/secret.xml error: internal error: a secret with UUID bd136bb0-fd78-5429-ab80-80b8c571d821 already defined for use with client.openstack secret 2023-03-28 01:49:46.711176 | 48d539a1-1679-623b-0af7-000000004b45 | FATAL | Create containers managed by Podman for /var/lib/tripleo-config/container-startup-config/step_4 | dcn01-hci-0 | error={"changed": false, "msg": "Failed containers: nova_libvirt_init_secret"} Can you please tell me how I can undefine the existing secret? With regards, Swogat Pradhan

3 5

[oslo][heat][masakari][senlin][venus][all] oslo.db 13.0.0 will remove sqlalchemy-migrate support
by Stephen Finucane 30 Mar '23

30 Mar '23

tl;dr: Projects still relying on sqlalchemy-migrate for migrations need to start their switch to alembic immediately. Projects with "legacy" sqlalchemy-migrated based migrations need to drop them. A quick heads up that oslo.db 13.0.0 will be release in the next month or so and will remove sqlalchemy-migrate support and formally add support for sqlalchemy 2.x. The removal of sqlalchemy-migrate support should only affect projects using oslo.db's sqlalchemy-migrate wrappers, as opposed to using sqlalchemy-migrate directly. For any projects that rely on this functionality, a short-term fix is to vendor the removed code [1] in your project. However, I must emphasise that we're not removing sqlalchemy-migrate integration for the fun of it: it's not compatible with sqlalchemy 2.x and is no longer maintained. If your project uses sqlalchemy-migrate and you haven't migrated to alembic yet, you need to start doing so immediately. If you have migrated to alembic but still have sqlalchemy- migrate "legacy" migrations in-tree, you need to look at dropping these asap. Anything less will result in broken master when we bump upper-constraints to allow sqlalchemy 2.x in Bobcat. I've listed projects in $subject that appear to be using the removed modules. For more advice on migrating to sqlalchemy 2.x and alembic, please look at my previous post on the matter [2]. Cheers, Stephen [1] https://review.opendev.org/c/openstack/oslo.db/+/853025 [2] https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.…

3 3

[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 29 Mar '23

29 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 29 Mar '23

29 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 29 Mar '23

29 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 29 Mar '23

29 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