- openstack-discuss - lists.openstack.org

[neutron] Drivers meeting cancelled
by Rodolfo Alonso Hernandez 09 Dec '22

09 Dec '22

Hello Neutrinos: Due to the lack of agenda, today's meeting is cancelled. If you want to add any topic to this meeting, please check [1] and use the "on demand agenda" section. Regards. [1]https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

1 0

the zun cmd "python3 setup.py install" error(s)
by 无数的星球 09 Dec '22

09 Dec '22

system:ubuntu:20.04 useDocumentation:https://docs.openstack.org/zun/zed/install/controller-inst… root@controller:/var/lib/zun/zun# python3 setup.py install ERROR:root:Error parsing Traceback (most recent call last):   File "/usr/lib/python3/dist-packages/pbr/core.py", line 96, in pbr     attrs = util.cfg_to_args(path, dist.script_args)   File "/usr/lib/python3/dist-packages/pbr/util.py", line 271, in cfg_to_args     pbr.hooks.setup_hook(config)   File "/usr/lib/python3/dist-packages/pbr/hooks/__init__.py", line 25, in setup_hook     metadata_config.run()   File "/usr/lib/python3/dist-packages/pbr/hooks/base.py", line 27, in run     self.hook()   File "/usr/lib/python3/dist-packages/pbr/hooks/metadata.py", line 25, in hook     self.config['version'] = packaging.get_version(   File "/usr/lib/python3/dist-packages/pbr/packaging.py", line 874, in get_version     raise Exception("Versioning for this project requires either an sdist" Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository. It's also possible that there is a mismatch between the package name in setup.cfg and the argument given to pbr.version.VersionInfo. Project name zun was given, but was not able to be found. error in setup command: Error parsing /var/lib/zun/zun/setup.cfg: Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository. It's also possible that there is a mismatch between the package name in setup.cfg and the argument given to pbr.version.VersionInfo. Project name zun was given, but was not able to be found. root@controller:/var/lib/zun/zun# cryed: pip3 install --upgrade distribute pip3 install --upgrade tensorflow_gpu

3 2

Issue resizing volumes attached to running volume backed instances
by Jérôme BECOT 08 Dec '22

08 Dec '22

Hello Openstack, We have Ussuri deployed on a few clouds, and they're all plugged to PureStorage Arrays. We allow users to only use volumes for their servers. It means that each server disk is a LUN attached over ISCSI (with multipath) on the compute node hosting the server. Everything works quite fine, but we have a weird issue when extending volumes attached to running instances. The guests notice the new disk size .. of the last extent. Say I have a server with a 10gb disk. I add 5gb. On the guest, still 10gb. I add another 5gb, and on the guest I get 15, and so on. I've turned the debug mode on and I could see no error in the log. Looking closer at the log I could catch the culprit: 2022-12-08 17:35:13.998 46195 DEBUG os_brick.initiator.linuxscsi [] Starting size: *76235669504* 2022-12-08 17:35:14.028 46195 DEBUG os_brick.initiator.linuxscsi [] volume size after scsi device rescan *80530636800* extend_volume 2022-12-08 17:35:14.035 46195 DEBUG os_brick.initiator.linuxscsi [] Volume device info = {'device': '/dev/disk/by-path/ip-1...1:3260-iscsi-iqn.2010-06.com.purestorage:flasharray.x-lun-10', 'host': '5', 'channel': '0', 'id': '0', 'lun': '10'} extend_volume 2022-12-08 17:35:14.348 46195 INFO os_brick.initiator.linuxscsi [] Find Multipath device file for volume WWN 3624... 2022-12-08 17:35:14.349 46195 DEBUG os_brick.initiator.linuxscsi [] Checking to see if /dev/disk/by-id/dm-uuid-mpath-3624.. exists yet. wait_for_path 2022-12-08 17:35:14.349 46195 DEBUG os_brick.initiator.linuxscsi [] /dev/disk/by-id/dm-uuid-mpath-3624... has shown up. wait_for_path 2022-12-08 17:35:14.382 46195 INFO os_brick.initiator.linuxscsi [] mpath(/dev/disk/by-id/dm-uuid-mpath-3624) *current size 76235669504* 2022-12-08 17:35:14.412 46195 INFO os_brick.initiator.linuxscsi [] mpath(/dev/disk/by-id/dm-uuid-mpath-3624) *new size 76235669504* 2022-12-08 17:35:14.413 46195 DEBUG oslo_concurrency.lockutils [] Lock "extend_volume" released by "os_brick.initiator.connectors.iscsi.ISCSIConnector.extend_volume" :: held 2.062s inner 2022-12-08 17:35:14.459 46195 DEBUG os_brick.initiator.connectors.iscsi [] <== extend_volume: return (2217ms) *76235669504* trace_logging_wrapper 2022-12-08 17:35:14.461 46195 DEBUG nova.virt.libvirt.volume.iscsi [] Extend iSCSI Volume /dev/dm-28; new_size=*76235669504* extend_volume 2022-12-08 17:35:14.462 46195 DEBUG nova.virt.libvirt.driver [] Resizing target device /dev/dm-28 to *76235669504* _resize_attached_volume The logs clearly shows that the rescan confirm the new size but when interrogating multipath, it does not. But requesting multipath few seconds after on the command line shows the new size as well. It explains the behaviour. I'm running Ubuntu 18.04 with multipath 0.7.4-2ubuntu3.2. The os-brick code for multipath is far more basic than the one in master branch. Maybe the multipath version installed is too recent for os-brick. Thanks for the help Jerome

1 0

(PXE FAILURE)using dnsmasq
by Adivya Singh 08 Dec '22

08 Dec '22

Hi Team. i m trying to setup PXE using dnsmasq, it fails on "Address listen on port 53" but i don't see any IP address listen on this port This IP 10.128.244.2 in the interface IP of the Infrastructure server where PXE is ported named as eno2 my dnsmasq.conf looks like this, All other setting are as per PXE configuration a default file under pxelinux.cfg and a installer in default, and a user-data file under the /var/www/html no-resolv interface=eno2 listen-address=10.128.244.2 dhcp-range=10.128.244.102,10.128.244.110,6h dhcp-boot=pxelinux/pxelinux.0 enable-tftp tftp-root=/var/lib/tftpboot Anyone having any idea on this error Regards Adivya Singh

2 1

[IRC Client] [Setup in Macbook] Best Practice to follow
by Rajesh Gunasekaran 07 Dec '22

07 Dec '22

Hello Team, I am really struggling with setting up the OpenStack IRC client in my new macbook pro! I made the switch from Windows to MAC recently. Could someone please advise what is the best practice I should follow to stay connected with #openstack community channels! in IRC while using mac -- Thanks, Rajesh

3 3

[ironic][release] Bugfix branch status and cleanup w/r/t zuul-config-errors
by Jay Faulkner 07 Dec '22

07 Dec '22

Hey all, I've been looking into the various zuul config errors showing up for Ironic-program branches. Almost all of our old bugfix branches are in the list. Additionally, not properly retiring the bugfix branches leads to an ever-growing list of branches which makes it a lot more difficult, for contributors and operators alike, to tell which ones are currently supported. I've put together a document describing the situation as it is now, and my proposal: https://etherpad.opendev.org/p/IronicBugfixBranchCleanup Essentially, I think we need to: - identify bugfix branches to cleanup (I've done this in the above etherpad, but some of the ) - clean them up (the next step) - update Ironic policy to set a regular cadence for when to retire bugfix branches, and encode the process for doing so This means there are two overall questions to answer in this email: 1) Mechanically, what's the process for doing this? I don't believe the existing release tooling will be useful for this, but I'm not 100% sure. I've pulled (in the above etherpad and a local spreadsheet) the last SHA for each branch; so we should be able to EOL these branches similarly to how we EOL stable branches; except manually instead of with tooling. Who is going to do this work? (I'd prefer releases team continue to hold the keys to do this; but I understand if you don't want to take on this manual work). 2) What's the pattern for Ironic to adopt regarding these branches? We just need to write down the expected lifecycle and enforce it -- so we prevent being this deep into "branch debt" in the future. What do folks think? - Jay Faulkner

4 6

[ironic][stable] Cleanup of clerical issues in ironic-stable-maint group
by Jay Faulkner 07 Dec '22

07 Dec '22

Hey all, I was looking over Ironic ACLs in Gerrit today, and I discovered the ironic-stable-maint group which is set to include ironic-core and stable-maint-core (as expected) -- but I also discovered a member in this list who is no longer a core reviewer, or active contributor to Ironic (Jim Rollenhagen). Lucky for us, Jim is a nice guy and we all trust him, and this access hasn't been used. In order to prevent this from happening in the future, I've removed all individual members from the ironic-stable-maint group and left it inheriting from ironic-core. The effective difference is just that Jim has been removed. tl;dr: The effective ironic-stable-maint core group has been dropped by one; Jim Rollenhagen was mistakenly left in the list. Thanks, Jay Faulkner

1 0

[Manila] S-RBAC Hack-a-thon
by Liron Kuchlani 07 Dec '22

07 Dec '22

Hi everyone, We are planning a Hack-a-thon for secure RBAC between Wed 12/07 to Thur 12/08 with Fri 12/09 as needed for code reviews. The session will take place between 15:00 UTC and 15:30 UTC. Join meeting: https://bluejeans.com/8520212381 Please find below helpful references and links, Openstack S-RBAC docs [0] Manila-tempest-plugin S-RBAC tests [1] S-RBAC collab review [2] Manila Secure RBAC Antelope PTG etherpad [3] Openstack Shared File Systems API documentation [4] S-RBAC code reviews [5] S-RBAC Kanban [6] [0] https://docs.openstack.org/patrole/latest/rbac-overview.html [1] https://github.com/openstack/manila-tempest-plugin/tree/master/manila_tempe… [2] https://etherpad.opendev.org/p/Manila-S-RBAC-collaborative-review [3] https://etherpad.opendev.org/p/antelope-ptg-manila-srbac [4] https://docs.openstack.org/api-ref/shared-file-system [5] https://review.opendev.org/q/topic:secure-rbac+project:openstack/manila-tem… [6] https://tree.taiga.io/project/silvacarloss-manila-tempest-plugin-rbac/kanban Hope you can all join us, -- Thanks, Liron

1 1

[largescale-sig] Next meeting: Dec 7, 15utc
by Thierry Carrez 07 Dec '22

07 Dec '22

Hi everyone, Contrary to previous indications, the Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 15UTC. You can doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20221207T15 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 1

[Horizon] How to enforce particular language on login
by A Tom 07 Dec '22

07 Dec '22

Hi everyone, I have a question regarding languages in Horizon - is there any way to enforce different language for different users - I mean without user interaction. Like user account is created and since then the default language for the user is set. Can it be done via Horizon API/config? Or maybe as Domain/Project properties? And second question - what about two different Horizons to one openstack? I mean every resorces are the same, but first Horizon has FQDN X-company.YY and is branded with X-company logo, and the other one has FQDN Y-company.ZZ and is branded wit Y-company logo - is such setup possible/right? OR maybe also two domains should be used? Best regards Adam Tomas

1 0

[cinder] Bug Report from 12-07-2022
by Sofia Enriquez 07 Dec '22

07 Dec '22

This is a bug report from 11-30-2022 to 12-07-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Medium - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025028 "[Debian] python-cinderclient: (autopkgtest) needs update for python3.11: conflicting subparser: another-fake-action." - https://bugs.launchpad.net/cinder/+bug/1998083 "volume_attachement entries are not getting deleted from DB." Unassigned. Marked as duplicate - https://bugs.launchpad.net/cinder/+bug/1998369 "[NFS] Creating an encrypted volume from an image overwrites the volume file with a broken symlink." Cheers, -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[mistral] Mistral maintenance and PTL
by Axel Vanzaghi 07 Dec '22

07 Dec '22

Hello everyone, Let me introduce myself, Axel Vanzaghi, first used OpenStack in 2015 and got back to it when I joined OVHCloud as SRE. Here at OVHCloud, we make an intensive use of Mistral in our internals processes, so we don't want to see it going deprecated [1] or abandonned. We decided to take action to maintain it, first by proposing someone to be the PTL for Mistral [2]. I proposed myself for this role. Yet, my experience with Mistral is only being an user of it, I worked on some of our workflow. However, I really liked what we could do with the tool so I'm willing to learn more and contribute on this project as I will be able to have time for it. Our first goal is to maintain the project alive, but new features will still be welcomed. Regards, Axel Vanzaghi [1] https://review.opendev.org/c/openstack/governance/+/866562 [2] https://lists.openstack.org/pipermail/openstack-discuss/2021-February/02015…

1 0

[neutron] Issue during the EOL of Queens, Rocky and Stein branches
by Rodolfo Alonso Hernandez 07 Dec '22

07 Dec '22

Hello all: In [1], the Neutron team transitioned all projects to EOL. However, because of a loose patch merged after the branch freeze, the automated tools can't finish the EOL task. Yesterday, during the Neutron team meeting [3], the attendants agreed to skip this last patch (that changes one line in the documentation) and comment on the affected stable release patches. This mail is to confirm that and to ask the QA team to manually perform this action. We'll be more careful in the future. Regards. [1]https://review.opendev.org/c/openstack/releases/+/862937 [2]https://review.opendev.org/q/Ie8dd684a7b79b0a322b1f2d17fffb4d58cfe94fc [3] https://meetings.opendev.org/meetings/networking/2022/networking.2022-12-06…

1 0

[heat][release] Proposing to EOL Rocky and Stein
by Brendan Shephard 06 Dec '22

06 Dec '22

Hi, We were discussing some of the older branches we have and thought it was about time we start moving some of them to EOL. Initially, I would like to move Rocky and Stein to EOL and have done so here: https://review.opendev.org/c/openstack/releases/+/866135 We would also like to move Train to EOL as well, pending a few changes being merged. I wanted to reach out and ensure there is no objections here to any of these branches being EOL’d. Feel free to voice any concerns, otherwise I will move forward with that next week. Cheers, Brendan Shephard Senior Software Engineer Red Hat Australia

2 1

[all][tc] Technical Committee next weekly meeting on 2022 Dec 7 at 1600 UTC
by Ghanshyam Mann 06 Dec '22

06 Dec '22

Hello Everyone, The technical Committee's next weekly meeting is scheduled for 2022 Dec 7, at 1600 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Tuesday, Dec 6 at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[openstack-ansible] Meetings on December 27 and January 3 cancelled
by Dmitriy Rabotyagov 06 Dec '22

06 Dec '22

Hi folks, During today's meeting we have agreed on cancelling our regular weekly meetings on December 27 2022 and January 3 2022. We still have meetings on December 13 and December 20 before this small break.

1 0

[openstack-ansible] CI is broken - hold on rechecks
by Dmitriy Rabotyagov 06 Dec '22

06 Dec '22

Hi folks, After merging [1] all our CI tests seem broken until we merge [2], so please hold on all your rechecks. With that being said, we need to focus on landing 862924 or merge temporary workaround to the integrated repo to define neutron_ml2_drivers_type and neutron_plugin_base for other checks to pass without [2]. [1] https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/865961 [2] https://review.opendev.org/c/openstack/openstack-ansible/+/862924

1 1

[publiccloud-sig] Bi-weekly meeting reminder
by Tobias Rydberg 06 Dec '22

06 Dec '22

Hi everyone, Tomorrow it's time again for our bi-weekly meeting, 0800 UTC in #openstack-operators. Etherpad can be found here [0]. Hope to chat with you tomorrow! [0] https://etherpad.opendev.org/p/publiccloud-sig-meeting BR, Tobias Rydberg

1 0

[keystone] Federation fix for numerical groups
by Mohammed Naser 06 Dec '22

06 Dec '22

Hi folks, I've pushed up this patch for a few weeks now with no response, could we please have a look at it? https://review.opendev.org/c/openstack/keystone/+/860726 Thanks, Mohammed -- Mohammed Naser VEXXHOST, Inc.

2 1

Need assistance
by Gk Gk 05 Dec '22

05 Dec '22

Hi, We have a SR-IOV guest whose xml looks like shown below: ------ <interface type='hostdev' managed='yes'> <mac address='fa:16:3e:3d:72:18'/> <driver name='vfio'/> <source> <address type='pci' domain='0x0000' bus='0x01' slot='0x12' function='0x7'/> </source> <vlan> <tag id='2'/> </vlan> <alias name='hostdev0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </interface> ---- How to find the network statistics for the virtual function assigned to the VM above from the ethtool -S output shown below: --- ethtool -S eno12409 NIC statistics: rx_unicast: 2890507 tx_unicast: 1279755 rx_multicast: 101903131 tx_multicast: 363832 rx_broadcast: 1496406 tx_broadcast: 1052 rx_bytes: 10084560360 tx_bytes: 225469520 rx_dropped: 0 rx_unknown_protocol: 0 rx_alloc_fail: 0 rx_pg_alloc_fail: 0 tx_errors: 0 tx_linearize: 0 tx_busy: 0 tx_restart: 0 tx_queue_0_packets: 120328 tx_queue_0_bytes: 15218021 tx_queue_1_packets: 185835 tx_queue_1_bytes: 33463904 tx_queue_2_packets: 255145 tx_queue_2_bytes: 62401952 tx_queue_3_packets: 73719 tx_queue_3_bytes: 9766278 tx_queue_4_packets: 75719 tx_queue_4_bytes: 13886665 tx_queue_5_packets: 756632 tx_queue_5_bytes: 64787766 tx_queue_6_packets: 127836 tx_queue_6_bytes: 13422778 tx_queue_7_packets: 49417 tx_queue_7_bytes: 7596442 rx_queue_0_packets: 103727545 rx_queue_0_bytes: 6961254601 rx_queue_1_packets: 326249 rx_queue_1_bytes: 454984714 rx_queue_2_packets: 242553 rx_queue_2_bytes: 339238020 rx_queue_3_packets: 183649 rx_queue_3_bytes: 244280310 rx_queue_4_packets: 405611 rx_queue_4_bytes: 495795368 rx_queue_5_packets: 227854 rx_queue_5_bytes: 236190286 rx_queue_6_packets: 193401 rx_queue_6_bytes: 271337926 rx_queue_7_packets: 982683 rx_queue_7_bytes: 447042416 rx_bytes.nic: 12401182418323 tx_bytes.nic: 74986406490 rx_unicast.nic: 8485232145 tx_unicast.nic: 761643543 rx_multicast.nic: 101957596 tx_multicast.nic: 388091 rx_broadcast.nic: 1495740 tx_broadcast.nic: 1718 tx_errors.nic: 0 tx_timeout.nic: 0 rx_size_64.nic: 167990805 tx_size_64.nic: 244373395 rx_size_127.nic: 240074370 tx_size_127.nic: 466106113 rx_size_255.nic: 39290324 tx_size_255.nic: 29943862 rx_size_511.nic: 6918699 tx_size_511.nic: 4570812 rx_size_1023.nic: 22389241 tx_size_1023.nic: 15207161 rx_size_1522.nic: 8112022042 tx_size_1522.nic: 1832009 rx_size_big.nic: 0 tx_size_big.nic: 0 link_xon_rx.nic: 0 link_xon_tx.nic: 0 link_xoff_rx.nic: 0 link_xoff_tx.nic: 0 tx_dropped_link_down.nic: 0 rx_undersize.nic: 0 rx_fragments.nic: 0 rx_oversize.nic: 0 rx_jabber.nic: 0 rx_csum_bad.nic: 0 rx_length_errors.nic: 0 rx_dropped.nic: 0 rx_crc_errors.nic: 0 illegal_bytes.nic: 0 mac_local_faults.nic: 0 mac_remote_faults.nic: 0 fdir_sb_match.nic: 0 fdir_sb_status.nic: 1 tx_priority_0_xon.nic: 0 tx_priority_0_xoff.nic: 0 tx_priority_1_xon.nic: 0 tx_priority_1_xoff.nic: 0 tx_priority_2_xon.nic: 0 tx_priority_2_xoff.nic: 0 tx_priority_3_xon.nic: 0 tx_priority_3_xoff.nic: 0 tx_priority_4_xon.nic: 0 tx_priority_4_xoff.nic: 0 tx_priority_5_xon.nic: 0 tx_priority_5_xoff.nic: 0 tx_priority_6_xon.nic: 0 tx_priority_6_xoff.nic: 0 tx_priority_7_xon.nic: 0 tx_priority_7_xoff.nic: 0 rx_priority_0_xon.nic: 0 rx_priority_0_xoff.nic: 0 rx_priority_1_xon.nic: 0 rx_priority_1_xoff.nic: 0 rx_priority_2_xon.nic: 0 rx_priority_2_xoff.nic: 0 rx_priority_3_xon.nic: 0 rx_priority_3_xoff.nic: 0 rx_priority_4_xon.nic: 0 rx_priority_4_xoff.nic: 0 rx_priority_5_xon.nic: 0 rx_priority_5_xoff.nic: 0 rx_priority_6_xon.nic: 0 rx_priority_6_xoff.nic: 0 rx_priority_7_xon.nic: 0 rx_priority_7_xoff.nic: 0 ----- Please help Thanks Kumar

2 1

[nova][placement][tempest] Hold your rechecks
by Sylvain Bauza 05 Dec '22

05 Dec '22

Sorry folks, that's kind of an email I hate writing but let's be honest : our gate is busted. Until we figure out a correct path for resolution, I hereby ask you to *NOT* recheck in order to not spill our precious CI resources for tests that are certain to fail. Long story story, there are currently two problems : #1 https://launchpad.net/bugs/1940425 nova-ovs-hybrid-plug and nova-next jobs 100% fail due to a port remaining in down state. #2 https://bugs.launchpad.net/nova/+bug/1960346 nova-lvm job 100% fails due to a volume detach failure probably due to QEMU #1 is currently investigated by the Neutron team meanwhile a patch [1] has been proposed against Zuul to skip the failing tests. Unfortunately, this patch [1] is unable to merge due to #2. #2 has a Tempest patch that's being worked on [2] but the current state of this patch is WIP. We somehow need to have an agreement on the way forward during this afternoon (UTC) to identify whether we can reasonably progress on [2] or skip the failing tests on nova-lvm. Again, sorry about the bad news and I'll keep you informed. -Sylvain [1] https://review.opendev.org/c/openstack/nova/+/865658/ [2] https://review.opendev.org/c/openstack/tempest/+/842240

2 5

[ironic] Meetings cancelled Dec 26, Jan 2
by Jay Faulkner 05 Dec '22

05 Dec '22

Hey all, Ironic team decided to cancel our meetings Dec 26, 2022 and Jan 2, 2023 to allow contributors to focus on family and friends over the holiday. Thanks for the hard work in 2022. If there are any concerns for Ironic during those weeks, please email the list or ask in IRC. Thanks, Jay Faulkner

1 0

[CFP] FOSDEM 2023 Virt & IaaS DevRoom (proposal submissions date: 10Dec2022)
by Kashyap Chamarthy 05 Dec '22

05 Dec '22

(I forgot to send this earlier, but there' still 5 more days to go) tl;dr: Please submit the proposals by *10 Dec 2022*. We are excited to announce that the call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2023, to be hosted on February 4th 2023. This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, KubeVirt, QEMU, KVM, and Foreman. We would like to invite all those who are involved in these fields to submit your proposals by December 10th, 2022. Important Dates --------------- Submission deadline: 10th December 2022 Acceptance notifications: 15th December 2022 Final schedule announcement: 20th December 2022 Conference devroom: first half of 4th February 2023 About the Devroom ----------------- The Virtualization & IaaS devroom will feature session topics such as open source hypervisors or virtual machine managers such as Xen Project, KVM, bhyve and VirtualBox as well as Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, OpenStack, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Submit Your Proposal -------------------- All submissions must be made via the Pentabarf event planning site[1]. If you have not used Pentabarf before, you will need to create an account. If you submitted proposals for FOSDEM in previous years, you can use your existing account. After creating the account, select Create Event to start the submission process. Make sure to select Virtualization and IaaS devroom from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. Submission Guidelines --------------------- We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Submission Guidelines --------------------- Mentored presentations will have 25-minute slots, where 20 minutes will include the presentation and 5 minutes will be reserved for questions. The number of newcomer session slots is limited, so we will probably not be able to accept all applications. You must submit your talk and abstract to apply for the mentoring program, our mentors are volunteering their time and will happily provide feedback but won't write your presentation for you! If you are experiencing problems with Pentabarf, the proposal submission interface, or have other questions, you can email our devroom mailing list[2] and we will try to help you. How to Apply ------------ In addition to agreeing to video recording and confirming that you can attend FOSDEM in case your session is accepted, please write "speaker mentoring program application" in the "Submission notes" field, and list any prior speaking experience or other relevant information for your application. Code of Conduct --------------- Following the release of the updated code of conduct for FOSDEM, we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Call for Volunteers ------------------- We are also looking for volunteers to help run the devroom. We need assistance watching time for the speakers, and helping with video for the devroom. Please contact devroom mailing list[2] for more information. Questions? ---------- If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] https://penta.fosdem.org/submission [2] iaas-virt-devroom at lists.fosdem.org PS: This is a formatted version of the official announce: https://lists.fosdem.org/pipermail/fosdem/2022q4/003473.html -- /kashyap

1 0

[neutron] Bug deputy - report from the week of Nov 28th
by Slawek Kaplonski 05 Dec '22

05 Dec '22

Hi, I was bug deputy this last week. It was pretty busy week and we had a lot of bugs reported. Here's the summary of them: Critical https://bugs.launchpad.net/neutron/+bug/1998474 - [UT] Random failure of "test_meter_manager_allocate_meter_id" - needs assignee https://bugs.launchpad.net/neutron/+bug/1998353 - Fullstack: test_packet_rate_limit_qos_policy_rule_lifecycle failing - assigned to Rodolfo, fix proposed already https://bugs.launchpad.net/neutron/+bug/1998343 - Unittest test_distributed_port_binding_deleted_by_port_deletion fails: DeprecationWarning('ssl.PROTOCOL_TLS is deprecated') - assigned to Anton Kurbatov, fix proposed already, https://bugs.launchpad.net/neutron/+bug/1995031 - [CI][periodic] neutron-functional-with-uwsgi-fips job failing - assigned to Lajos, it can be the same issue as LP#1998337 High https://bugs.launchpad.net/neutron/+bug/1998228 - [UT] Error in "test_get_vlan_device_name" with n-lib 3.2.0 - In progress, patch https://review.opendev.org/c/openstack/neutron/+/866038 https://bugs.launchpad.net/neutron/+bug/1998226 - [fullstack] Error in "test_concurrent_router_subnet_attachment_overlapping_cidr_" - seems like real issue catched by fullstack test, assigned to Fernando Royo https://bugs.launchpad.net/neutron/+bug/1998104 - dynamic-routing: address_scope calculation error - In progress, fix proposed already https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/863708 https://bugs.launchpad.net/neutron/+bug/1998621 - dnsmasq on DHCP Agent does not listen on tcp/53 after dnsmasq restart - In progress, fix already proposed https://review.opendev.org/c/openstack/neutron/+/866489 Medium https://bugs.launchpad.net/neutron/+bug/1998337 - test_dvr_router_lifecycle_ha_with_snat_with_fips fails occasionally in the gate - Needs assignee https://bugs.launchpad.net/neutron/+bug/1998751 - [L3][DVR][vlan] HA VRRP traffic flooding on physical bridges on compute nodes, needs assignee https://bugs.launchpad.net/neutron/+bug/1998749 - [L3][DVR][vlan] east-west traffic flooding on physical bridges, needs assignee Low https://bugs.launchpad.net/neutron/+bug/1998108 - Move "ChassisBandwidthConfigEvent" registration to "OvnSbIdl" class initialization - In progress, patch https://review.opendev.org/c/openstack/neutron/+/865857 https://bugs.launchpad.net/neutron/+bug/1998085 - Manual install & Configuration in Neutron incorrect vni_ranges leads to error - In progress, patch https://review.opendev.org/c/openstack/neutron/+/865960 https://bugs.launchpad.net/neutron/+bug/1998317 - CachedResourceConsumerTracker update triggered for every command - assigned to Szymon Wróblewski Whishlist (RFEs) https://bugs.launchpad.net/neutron/+bug/1998202 - [RFE] Allow shared resource providers for physical and tunnelled networks - assigned to Rodolfo https://bugs.launchpad.net/neutron/+bug/1998608 - [RFE] A new OVN monitor agent running on each compute node - assigned to Rodolfo https://bugs.launchpad.net/neutron/+bug/1998609 - [RFE] - OVN Distributed routing + IPv6 support - needs triaging from OVN and L3 teams, Others https://bugs.launchpad.net/neutron/+bug/1998235 - Allowed address pairs and dvr routers - duplicate of the old bug https://bugs.launchpad.net/neutron/+bug/1774459 which was never fixed, -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[cinder][kolla][OpenstackAnsible] Zed Cycle-Trailing Release Deadline
by Thierry Carrez 05 Dec '22

05 Dec '22

Hello teams with cycle-trailing projects, The Zed cycle-trailing release deadline[1] is next week ! All projects following the cycle-trailing release model must release their Zed deliverables by Dec 14th, 2022. [1] https://releases.openstack.org/antelope/schedule.html#a-cycle-trail The following trailing projects haven't been released yet for Zed (aside the release candidates versions if exists). Cinder team's deliverables: - cinderlib OSA team's deliverables: - openstack-ansible Kolla team's deliverables: - kayobe - kolla - kolla-ansible - ansible-collection-kolla This is just a friendly reminder to allow you to release these projects in time. Do not hesitate to ping the release team if you have any questions or concerns. -- Thierry Carrez (ttx)

1 0

[cinder] Cinder Midcycle - 1 (R-16) Summary
by Rajat Dhasmana 04 Dec '22

04 Dec '22

Hello Argonauts, The summary for midcycle-1 held on 30th November, 2022 between 1400-1600 UTC is available here[1]. Please go through the etherpad and recordings for the discussion. [1] https://wiki.openstack.org/wiki/CinderAntelopeMidCycleSummary - Rajat Dhasmana

1 0

Upgrade Ceph 16.2.10 to 17.2.x for Openstack Wallaby RBD storage
by Zakhar Kirpichenko 04 Dec '22

04 Dec '22

Hi! I'm planning to upgrade our Ceph cluster from Pacific (16.2.10) to Quincy (17.2.x). The cluster is used for Openstack block storage (RBD), Openstack version is Wallaby built on Ubuntu 20.04. Is anyone using Ceph Quincy (17.2.x) with Openstack Wallaby? If you are, please let me know if you've encountered any issues specific to these Ceph and Openstack versions. Many thanks! Best regards, Zakhar

1 0

Re: Unable to access Internet from an instance and accessing instance using floating-point IPs from external network
by Eugen Block 03 Dec '22

03 Dec '22

Hi, if you want people to reply you should keep the mailing list in the loop. Also please don't paste pictures but terminal output as plain text so it won't get lost. >> From my controller site: >> External-internet = 192.168.1.118 >> Internal-network = 10.42.0.189 Seems like you meant it the other way around looking at the other networks. >> My external network details is shown below I don't see a segmentation ID for the external network, we create provider (external) networks with the same segmentation ID as the corresponding VLAN in our environment has. The rest of the information on the pictures is not readable to me, please paste the security-group rules as text. >> Apart from all the above information, I will briefly talk about what I >> have enabled in my global.yml file. I have set the >> kolla_internal_vip_address to "192168.1.200", kolla_external_vip_address to >> "10.42.0.200", enable_haproxy to "yes" and other core components of >> openstack was enabled. I'm not familiar with kolla so I can't really say what else could be missing or not. You could disable the port security for your instance to see if that helps, otherwise use tcpdump on control and compute node to see where the packets get lost and which vlans are in use. I'm not sure if that will resolve it but I believe your external network should have a segmentation ID. Zitat von vincent lee <vincentlee676(a)gmail.com>: > Hi, one last thing I would like to add on is the setting of my openvswitch > configuration. > [image: image.png] > [image: image.png] > > > On Wed, Nov 30, 2022 at 1:39 PM vincent lee <vincentlee676(a)gmail.com> wrote: > >> Hi Eugen, >> Sorry for causing any confusion in my previous emails and I will summarize >> the main issue here. After deploying openstack from a fresh installation, I >> have not modified the security group when working creating an instance or a >> container. >> >> From my controller site: >> External-internet = 192.168.1.118 >> Internal-network = 10.42.0.189 >> >> For my compute host 1: >> Internal-network = 192.168.1.115 >> >> For my compute host 2: >> Internal-network = 192.168.1.108 >> >> My current issue is that when I created an instance which ran >> successfully, I was not able to ping that instance from my controller via >> the external network. Besides, I was also not able to ping the internet >> (8.8.8.8) inside of the instance. >> >> However, I was able to ping to the external network (10.42.0.67) from >> inside of the newly created instance itself. In other words, the router is >> communicating correctly. I have attached an image of my network topology as >> shown below. >> [image: image.png] >> Inside of my instance >> [image: image.png] >> I have attached an image of my router details as shown below >> [image: image.png] >> My external network details is shown below >> [image: image.png] >> external network's subnet detail is shown below >> [image: image.png] >> My internal network details is shown below >> [image: image.png] >> internal network's subnet is shown below >> [image: image.png] >> My floating IPs is shown below >> [image: image.png] >> My current security group rules is shown below >> [image: image.png] >> My system information is shown below >> [image: image.png] >> Apart from all the above information, I will briefly talk about what I >> have enabled in my global.yml file. I have set the >> kolla_internal_vip_address to "192168.1.200", kolla_external_vip_address to >> "10.42.0.200", enable_haproxy to "yes" and other core components of >> openstack was enabled. >> >> Best, >> Vincent >> >> >> >> On Wed, Nov 30, 2022 at 2:30 AM Eugen Block <eblock(a)nde.ag> wrote: >> >>> So you did modify the default security-group, ports 8000 and 8080 are >>> not open by default. Anyway, can you please clarify what doesn't work >>> exactly? >>> Does the instance have an IP in the public network but the router is >>> not pingeable (but that is not necessarily an issue) and you can't >>> access it via which protocols? Does SSH work? Is the access blocked by >>> a http_proxy? >>> >>> >>> Zitat von vincent lee <vincentlee676(a)gmail.com>: >>> >>> > To add on to my previous email, I have attached an image of my security >>> > group as shown below. >>> > >>> > Best regards, >>> > Vincent >>> > >>> > On Tue, Nov 22, 2022 at 3:58 AM Eugen Block <eblock(a)nde.ag> wrote: >>> > >>> >> Just one more thing to check, did you edit the security-group rules to >>> >> allow access to the outside world? >>> >> >>> >> Zitat von Adivya Singh <adivya1.singh(a)gmail.com>: >>> >> >>> >> > it should be missing a default route most of the time. >>> >> > or check IP tables on router namespace the DNAT and SNAT are working >>> >> > properly >>> >> > >>> >> > >>> >> > >>> >> > On Tue, Nov 22, 2022 at 9:40 AM Tobias McNulty < >>> tobias(a)caktusgroup.com> >>> >> > wrote: >>> >> > >>> >> >> On Mon, Nov 21, 2022 at 7:39 PM vincent lee < >>> vincentlee676(a)gmail.com> >>> >> >> wrote: >>> >> >> >>> >> >>> After reviewing the post you shared, I believe that we have the >>> correct >>> >> >>> subnet. Besides, we did not modify anything related to the >>> cloud-init >>> >> for >>> >> >>> openstack. >>> >> >>> >>> >> >> >>> >> >> I didn't either. But I found it's a good test of the network! If >>> you are >>> >> >> using an image that doesn't rely on it you might not notice (but I >>> >> >> would not recommend that). >>> >> >> >>> >> >> >>> >> >>> After launching the instances, we are able to ping between the >>> >> instances >>> >> >>> of the same subnet. However, we are not able to receive any >>> internet >>> >> >>> connection within those instances. From the instance, we are able >>> to >>> >> ping >>> >> >>> the router IP addresses 10.42.0.56 and 10.0.0.1. >>> >> >>> >>> >> >> >>> >> >> To make sure I understand: >>> >> >> - 10.42.0.56 is the IP of the router external to OpenStack that >>> provides >>> >> >> internet access >>> >> >> - This router is tested and working for devices outside of OpenStack >>> >> >> - OpenStack compute instances can ping this router >>> >> >> - OpenStack compute instances cannot reach the internet >>> >> >> >>> >> >> If that is correct, it does not sound like an OpenStack issue >>> >> necessarily, >>> >> >> but perhaps a missing default route on your compute instances. I >>> would >>> >> >> check that DHCP is enabled on the internal subnet and that it's >>> >> providing >>> >> >> everything necessary for an internet connection to the instances. >>> >> >> >>> >> >> Tobias >>> >> >> >>> >> >> >>> >> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> > >>> > -- >>> > thanks you. >>> > vincentleezihong >>> > 2garnet >>> > form2 >>> >>> >>> >>> >>> >> >> -- >> thanks you. >> vincentleezihong >> 2garnet >> form2 >> >> > > -- > thanks you. > vincentleezihong > 2garnet > form2

2 1

[all][tc] What's happening in Technical Committee: summary 2022 Dec 02: Reading: 5 min
by Ghanshyam Mann 02 Dec '22

02 Dec '22

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on Nov 30. Most of the meeting discussions are summarized in this email. Meeting logs are available @ https://meetings.opendev.org/meetings/tc/2022/tc.2022-11-30-16.00.log.html * Next TC weekly meeting will be on Dec 7 Wed at 16:00 UTC, Feel free to add the topic to the agenda[1] by Dec 6. 2. What we completed this week: ========================= * FIPS testing on Ubuntu paid subscription We discussed it in TC meeting and after considering the currently available options, TC agreed to go for this[2]. We know it is paid subscription (given by Ubuntu as free to OpenStack upstream CI) and we should use the free open source things to test the upstream code but we do not have any other setup ready for FIPS testing (CentOSstream is not stable enough to add voting job, Debian is not tested broadly in all projects so it may take more time to add the voting job in projects) For now, testing FIPS with Ubuntu paid token is best possible go ahead and if we have any open source/free/stable version available in any distro then we can move FIPS job on that. * Added Skyline repository for OpenStack-Ansible[3] * Added the manila-infinidat charm to Openstack charms[4] * Added the cinder-infinidat charm to Openstack charms[5] 3. Activities In progress: ================== TC Tracker for 2023.1 cycle --------------------------------- * Current cycle working items and their progress are present in 2023.1 tracker etherpad[6]. Open Reviews ----------------- * Three open reviews for ongoing activities[7]. Technical Election changes (Extending Nomination and voting period) ---------------------------------------------------------------------------------- This is in review and positive response so far[8]. Renovate translation SIG i18 ---------------------------------- * No specific update for this week and it will be discussed with the Foundation staff and Board members in Dec 6th board meeting. Adjutant situation (project is not active) ----------------------------------------------- Proposal to mark Adjutant as inactive is up[9] and ready for review. I have emailed about it to current PTL also. Project updates ------------------- * Add the infinidat-tools subordinate charm to OpenStack charms[10] 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[11]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15:00 UTC [12] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://lists.openstack.org/pipermail/openstack-discuss/2022-November/03124… [2] https://meetings.opendev.org/meetings/tc/2022/tc.2022-11-30-16.00.log.html#… [3] https://review.opendev.org/c/openstack/governance/+/863166 [4] https://review.opendev.org/c/openstack/governance/+/864068 [5] https://review.opendev.org/c/openstack/governance/+/863958 [6] https://etherpad.opendev.org/p/tc-2023.1-tracker [7] https://review.opendev.org/q/projects:openstack/governance+status:open [8] https://review.opendev.org/c/openstack/governance/+/865367 [9] https://review.opendev.org/c/openstack/governance/+/849153 [10] https://review.opendev.org/c/openstack/governance/+/864067 [11] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [12] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann

1 0

[neutron] Neutron drivers meeting cancelled
by Rodolfo Alonso Hernandez 02 Dec '22

02 Dec '22

Hello Neutrinos: Due to the lack of agenda, *today's meeting is cancelled*. I have one topic [1] I would like to discuss but I'll wait until I test the code and I'm sure the feature is working. Once this is done, I'll ask you to review it and vote for this RFE. Have a good weekend! [1]https://bugs.launchpad.net/neutron/+bug/1998202

1 0

[openstack-ansible] Removing support for Calico Network driver
by Dmitriy Rabotyagov 02 Dec '22

02 Dec '22

Hi everyone, Due to lack of maintainers of Calico driver support in OpenStack-Ansible we have decided to remove support for this driver. Eventually, CI was failing for Calico jobs for the last few cycles and we haven't seen any interest in further support of the feature. Patches for Calico removal are already proposed: https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/866123 https://review.opendev.org/c/openstack/openstack-ansible/+/866119 If you're interested in this driver and want to step in for fixing CI and supporting the feature, please let us know either by replying to this email or by voting accordingly for the mentioned patches. In case no negative feedback will be received we will merge them by the end of the next week, December 9 2022.

1 0

[Magnum] ls /etc/cni/net.d/ is emty
by Nguyễn Hữu Khôi 01 Dec '22

01 Dec '22

Hello guys. I use Magnum on Xena and I custom k8s cluster by labels. But My cluster is not ready and there is nothing in /etc/cni/net.d/ and my cluster said: container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized And this is my labels kube_tag=v1.21.8-rancher1,container_runtime=containerd,containerd_version=1.6.10,containerd_tarball_sha256=507f47716d7b932e58aa1dc7e2b3f2b8779ee9a2988aa46ad58e09e2e47063d8,calico_tag=v3.21.2,hyperkube_prefix= docker.io/rancher/ Note: I use Fedora Core OS 31 for images. Thank you. Nguyen Huu Khoi

2 3

[kolla-ansible][Yoga][Magnum] How to delete a cluster containing errors
by wodel youchi 30 Nov '22

30 Nov '22

Hi, I have a magnum cluster stack which contains errors in its constituents, some of the VMs (minions) that belong to that cluster do longer exist. When I try to delete the stack it fails, and I get DELETE aborted (Task delete from ResourceGroup "kube_minions" [fddb3056-9b00-4665-b0d6-c3d3f176814b] Stack "testcluter01-puf45b6dxmrn" [d10af7f2-6ecd-442b-b1f9-140b79e58d13] Timed out) Is there a way to force the deletion to proceed even with those errors? Regards.

3 6

[cinder] Bug report from 11-23-2022 to 11-30-2022
by Sofia Enriquez 30 Nov '22

30 Nov '22

No meeting today due to Antelope Midcycle-1 (R-18). This is a bug report from 11-23-2022 to 11-30-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Medium - https://bugs.launchpad.net/cinder/+bug/1998083 "volume_attachement entries are not getting deleted from DB." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1997980 "rbd: 'error updating features for image' when enabling multi-attach." Fix proposed to master. Low - https://bugs.launchpad.net/cinder/+bug/1997876 "Ceph backup: Improve error message when creating an incremental backup of a non-RBD volume." Unassigned. Cheers, Sofia -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[cinder] 2023.1 R-16 virtual mid cycle on 30th November (today)
by Rajat Dhasmana 30 Nov '22

30 Nov '22

Hello Argonauts, The first 2023.1 (Antelope) mid cycle R-16 will be held on 30th November (today) with the following details: Date: 30th November 2022 Time: 1400-1600 UTC Meeting link: https://bluejeans.com/556681290 Etherpad: https://etherpad.opendev.org/p/cinder-antelope-midcycles Thanks and regards Rajat Dhasmana

1 0

[neutron][releases] Proposing to EOL Train networking-ovn
by Rodolfo Alonso Hernandez 30 Nov '22

30 Nov '22

Hello: The transition of this branch to EM was done 1,5 years ago [1]. During this time the maintenance of Train networking-ovn has continued. However, due to the lack of time and personal resources, we can't properly maintain it. That leads to problems like [1]. The ML2/OVN driver was successfully merged in the Neutron repository in Ussury. We continue the development and improvement of this ML2 mechanism driver. A patch to mark this branch as EOL will be pushed in two weeks. If you have any inconvenience, please let me know in this mail chain or in IRC (ralonsoh, #openstack-neutron channel). You can also contact any Neutron core reviewer in the IRC channel. Regards. [1]https://review.opendev.org/c/openstack/releases/+/790760 [2]https://bugs.launchpad.net/neutron/+bug/1997262

1 0

Re: Unable to access Internet from an instance and accessing instance using floating-point IPs from external network
by Eugen Block 30 Nov '22

30 Nov '22

So you did modify the default security-group, ports 8000 and 8080 are not open by default. Anyway, can you please clarify what doesn't work exactly? Does the instance have an IP in the public network but the router is not pingeable (but that is not necessarily an issue) and you can't access it via which protocols? Does SSH work? Is the access blocked by a http_proxy? Zitat von vincent lee <vincentlee676(a)gmail.com>: > To add on to my previous email, I have attached an image of my security > group as shown below. > > Best regards, > Vincent > > On Tue, Nov 22, 2022 at 3:58 AM Eugen Block <eblock(a)nde.ag> wrote: > >> Just one more thing to check, did you edit the security-group rules to >> allow access to the outside world? >> >> Zitat von Adivya Singh <adivya1.singh(a)gmail.com>: >> >> > it should be missing a default route most of the time. >> > or check IP tables on router namespace the DNAT and SNAT are working >> > properly >> > >> > >> > >> > On Tue, Nov 22, 2022 at 9:40 AM Tobias McNulty <tobias(a)caktusgroup.com> >> > wrote: >> > >> >> On Mon, Nov 21, 2022 at 7:39 PM vincent lee <vincentlee676(a)gmail.com> >> >> wrote: >> >> >> >>> After reviewing the post you shared, I believe that we have the correct >> >>> subnet. Besides, we did not modify anything related to the cloud-init >> for >> >>> openstack. >> >>> >> >> >> >> I didn't either. But I found it's a good test of the network! If you are >> >> using an image that doesn't rely on it you might not notice (but I >> >> would not recommend that). >> >> >> >> >> >>> After launching the instances, we are able to ping between the >> instances >> >>> of the same subnet. However, we are not able to receive any internet >> >>> connection within those instances. From the instance, we are able to >> ping >> >>> the router IP addresses 10.42.0.56 and 10.0.0.1. >> >>> >> >> >> >> To make sure I understand: >> >> - 10.42.0.56 is the IP of the router external to OpenStack that provides >> >> internet access >> >> - This router is tested and working for devices outside of OpenStack >> >> - OpenStack compute instances can ping this router >> >> - OpenStack compute instances cannot reach the internet >> >> >> >> If that is correct, it does not sound like an OpenStack issue >> necessarily, >> >> but perhaps a missing default route on your compute instances. I would >> >> check that DHCP is enabled on the internal subnet and that it's >> providing >> >> everything necessary for an internet connection to the instances. >> >> >> >> Tobias >> >> >> >> >> >> >> >> >> >> >> > > -- > thanks you. > vincentleezihong > 2garnet > form2

1 0

[all][tc] Technical Committee next weekly meeting on 2022 Nov 30 at 1600 UTC
by Ghanshyam Mann 29 Nov '22

29 Nov '22

Hello Everyone, The technical Committee's next weekly meeting is scheduled for 2022 Nov 30, at 1600 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Tuesday, Nov 29 at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[Kolla-ansible][Neutron] VMs not getting public IPs if attached directly to public subnet
by wodel youchi 29 Nov '22

29 Nov '22

Hi, We have an HCI deployment with 3 controllers and 9 compute/storage nodes. Two of the controllers have the role of neutron server. The platform uses two bonded interfaces : bond1 : is used for : *neutron_external_interface* bond0 : with many vlans on top of it to segregate the rest of the networks : - bond0 : vlan natif used for nodes deployment (dhcp, tftp, pxeboot) - bond0.10 : vlan 10 ceph public - bond0.20 : vlan 20 ceph cluster - bond0.30 : vlan 30 API - bond0.40 : vlan 40 tunnel * - bond0.50 : vlan 50 Public network, here are the public IPs of the 03 controllers, the public horizon VIP interface is created here.* In our configuration we have *"enable_neutron_provider_networks = yes"*, which means that an instance can have a public IP directly without using a virtual-router + NAT. But it does not work. If we create and instance with a private network, then we attach to it a floating IP, the VM is reachable from the Internet, but if we attach the VM directly to the public network, it does not get an IP address from the public pool, we think it's a dhcp problem but we could not find the source, we think it's the *Vlan part.* The controllers are in Vlan 50, if we create a virtual-router it gets its public IP without any problem. But if we are not mistaken, if an instance is plugged directly into the public network, it uses bond1 to send its dhcp requests, but since this interface is not in vlan 50, the requests don't get to the controllers, is this right? If yes, is there a solution? can we use bond1.50 as an interface for kolla's *neutron_external_interface * instead? Regards.

3 3

[OVB - openstack-virtual-baremetal] - Douglas Viroel and Chandan Kumar as core
by Harald Jensas 29 Nov '22

29 Nov '22

Hi, After discussions with Douglas, Chandan and Ronelle Landy I would like to suggest adding Douglas and Chandan to the OVB core team. The repository have very little activity, i.e there is not a lot of review history to base the decision on. I did work with both individuals when onboarding new clouds to run TripleO CI jobs utilizing OVB, they have a good understanding of how the thing works. If there are no objections, I will add them to them as core reviewers next week. Regards, Harald

3 3

[openstack-ansible] Designate: role seems trying to update DNS server pools before syncing database
by Taltavull Jean-François 29 Nov '22

29 Nov '22

Hello, During the first run, the playbook 'os-designate-install.yml' fails and the 'designate-manage pool update' command produces the log line below: 'Nov 25 11:50:06 pp3controller1a-designate-container-53d945bb designate-manage[2287]: 2022-11-25 11:50:06.518 2287 CRITICAL designate [designate-manage - - - - -] Unhandled error: oslo_messaging.rpc.client.RemoteError: Remote error: ProgrammingError (pymysql.err.ProgrammingError) (1146, "Table 'designate.pools' doesn't exist")' Looking at the 'os_designate' role code shows that the handler ` Perform Designate pools update` is flushed before tables are created in the 'designate' database. O.S.: Ubuntu 20.04 OpenStack release: Wallaby OSA tag: 23.2.0 Regards, Jean-Francois

2 4

[neutron] neutron-db-manage multiple heads
by Eugen Block 29 Nov '22

29 Nov '22

Hi *, I'd like to ask you for advice on how to clean up my neutron db. At some point (which I don't know exactly, probably train) my neutron database got inconsistent, apparently one of the upgrades did not go as planned. The interesting thing is that the database still works, I just upgraded from ussuri to victoria where that issue popped up again during 'neutron-db-manage upgrade --expand', I'll add the information at the end of this email. Apparently, I have multiple heads, and one of them is from train, it seems as if I never ran --contract (or it failed and I didn't notice). Just some additional information what I did with this database: this cloud started out as a test environment with a single control node and then became a production environment. About two and a half years ago we decided to reinstall this cloud with version ussuri and import the databases. I had a virtual machine in which I upgraded the database dump from production to the latest versions at that time. That all worked quite well, I only didn't notice that something was missing. Now that I finished the U --> V upgrade I want to fix this inconsistency, I just have no idea how to do it. As I'm not sure how all the neutron-db-manage commands work exactly I'd like to ask for some guidance. For example, could the "stamp" command possibly help? Or how else can I get rid of the train head and/or how to get the train revision to "contract" so I can finish the upgrade and contract the victoria revision? I can paste the whole neutron-db history if necessary (neutron-db-manage history), please let me know what information would be required to get to the bottom of this. Any help is greatly appreciated! Thanks! Eugen ---snip--- controller01:~ # neutron-db-manage upgrade --expand [...] alembic.script.revision.MultipleHeads: Multiple heads are present for given argument 'expand@head'; 633d74ebbc4b, I38991de2b4 controller01:~ # neutron-db-manage current --verbose Running current for neutron ... INFO [alembic.runtime.migration] Context impl MySQLImpl. INFO [alembic.runtime.migration] Will assume non-transactional DDL. Current revision(s) for mysql+pymysql://neutron:XXXXX@controller.fqdn/neutron: Rev: bebe95aae4d4 (head) Parent: b5344a66e818 Branch names: contract Path: /usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/ussuri/contract/bebe95aae4d4_.py Rev: 633d74ebbc4b (head) Parent: 6c9eb0469914 Branch names: expand Path: /usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/train/expand/633d74ebbc4b_.py Rev: I38991de2b4 (head) Parent: 49d8622c5221 Branch names: expand Path: /usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/victoria/expand/I38991de2b4_source_and_destination_ip_prefix_neutron_metering_rule.py OK ---snip---

2 10

Re: Unable to access Internet from an instance and accessing instance using floating-point IPs from external network
by Tobias McNulty 29 Nov '22

29 Nov '22

On Mon, Nov 21, 2022 at 7:39 PM vincent lee <vincentlee676(a)gmail.com> wrote: > After reviewing the post you shared, I believe that we have the correct > subnet. Besides, we did not modify anything related to the cloud-init for > openstack. > I didn't either. But I found it's a good test of the network! If you are using an image that doesn't rely on it you might not notice (but I would not recommend that). > After launching the instances, we are able to ping between the instances > of the same subnet. However, we are not able to receive any internet > connection within those instances. From the instance, we are able to ping > the router IP addresses 10.42.0.56 and 10.0.0.1. > To make sure I understand: - 10.42.0.56 is the IP of the router external to OpenStack that provides internet access - This router is tested and working for devices outside of OpenStack - OpenStack compute instances can ping this router - OpenStack compute instances cannot reach the internet If that is correct, it does not sound like an OpenStack issue necessarily, but perhaps a missing default route on your compute instances. I would check that DHCP is enabled on the internal subnet and that it's providing everything necessary for an internet connection to the instances. Tobias

4 3

[all] Cargo Culted Tox install_command overrides
by Clark Boylan 28 Nov '22

28 Nov '22

A subset of tempest jobs recently began to exhibit some interesting behavior. The tox installation was finding the global pip installation instead of pip in the tox virtualenv which led to an attempt to install packages globally which failed. Eventually, I discovered the reason this happened was that virtualenv created a broken venv installation for tox, but this was made far more confusing by two tox settings in tempest's tox.ini: install_command and allowlist_externals. Tempest had overridden install_command to ` pip install {opts} {packages}` and set allowlist_externals to `*`. This allowed tox to find and use global pip without complaint. Tempest has since cleaned these up with this change [0], which should result in nicer error messages in the future if we have similar problems. I have noticed that many projects have cargo culted this configuration, particularly for install_command [1]. The default install_command for tox is `python -m pip install {opts} {packages}` [2]. This is almost equivalent to our overrides except that it uses pip as a module. This is important in this case because we don't install python2 regularly which means there is no `python` command except for in the created virtualenv where `python` == `python3`. The resulting behavior difference here would have been helpful to have when debugging the underlying issue in tempest. All that to say, I would suggest that those who have install_command set similarly to tempest remove this unnecessary configuration. Separately, setting allowlist_externals to `*` allows all global commands to run without complaint or an indication they are being used. Far fewer projects have this problem though [3]. Those that do should consider updating their config to explicitly list the commands they actually need from outside the virtualenv. Neither of these changes is critical, but I wanted people to be aware of this as we seem to have copied it all over the place. [0] https://review.opendev.org/c/openstack/tempest/+/865314 [1] https://codesearch.opendev.org/?q=install_command&i=nope&literal=nope&files… [2] https://tox.wiki/en/latest/config.html#conf-install_command [3] https://codesearch.opendev.org/?q=allowlist_externals%20%3D%20%5C*&i=nope&l…

1 0

[oslo] New driver for oslo.messaging
by 王坤田 28 Nov '22

28 Nov '22

Hello: I want to develop a new driver for oslo.messaging to use rocketmq in openstack environment. I wonder if the community need this new driver？ Best Regards！

4 3

[neutron] Bug deputy report, Nov. 21. - Nov. 27.
by Lajos Katona 28 Nov '22

28 Nov '22

Hi Neutron Team I was the bug deputy in neutron last week, please check my summary. Needs attention ================= * networking-ovn-dsvm-functional-py27 job killed on timeout in stable/train branch (https://bugs.launchpad.net/neutron/+bug/1997262) *Stable only* * [ovn-octavia-provider] Octavia LB stuck in PENDING_UPDATE after creation (https://bugs.launchpad.net/neutron/+bug/1997567 ) *HIGH* * neutron_lib.exceptions.InvalidInput: Invalid input for operation: Segmentation ID should be lower or equal to 4095 ( https://bugs.launchpad.net/neutron/+bug/1997955 ) *Incomplete* * related doc bug: Manual install & Configuration in Neutron incorrect vni_ranges leads to error (https://bugs.launchpad.net/neutron/+bug/1998085 ) *LOW* * Prevent initializing "ovn-router" service if OVN mech driver is not called (https://bugs.launchpad.net/neutron/+bug/1997970 ) *MEDIUM* * [fullstack] Error in "test_logging" ( https://bugs.launchpad.net/neutron/+bug/1997965 ) *High* In Progress ================= * [ovn-octavia-provider] HM not working for FIPs ( https://bugs.launchpad.net/neutron/+bug/1997418 ) * Neutron server doesn't wait for port DHCP provisioning while VM creation ( https://bugs.launchpad.net/neutron/+bug/1997492 ): https://review.opendev.org/c/openstack/neutron/+/865470 * "convert_to_sanitized_mac_address" shoudl accept netaddr.EUI type values ( https://bugs.launchpad.net/neutron/+bug/1997680 ): https://review.opendev.org/c/openstack/neutron-lib/+/865517 * after restart of a ovn-controller the agent is still down ( https://bugs.launchpad.net/neutron/+bug/1997982 ): https://review.opendev.org/c/openstack/neutron/+/865697 Already merged ================ * [DHCP] Error in "call_driver" method ( https://bugs.launchpad.net/neutron/+bug/1997964) https://review.opendev.org/c/openstack/neutron/+/840421

1 0

Does openstack have an official automatic evacuation instance scheme
by 韩光宇 28 Nov '22

28 Nov '22

Hi all, I would like to ask whether the openstack community has an official automatic evacuation instance scheme？ I have a openstack cluster, and all of glance, nova and cinder has used ceph. So I have a basic of instance HA. I want to imply automatic evacuation instance, but I'm a newer in this. Does the community have any related projects or recommended open source solutions? Any help is greatly appreciated! Thanks! Han

2 1

[neutron] Switching the ML2 driver in-place from linuxbridge to OVN for an existing Cloud
by Christian Rohmann 26 Nov '22

26 Nov '22

Hello openstack-discuss and neutron experts, I'd like to ask for your input and discussion on the idea of changing the ML2 driver for an existing cloud, read: changing a tire while still riding the bike. I actually like to find out if it's feasible to switch from the trusted Linuxbridge driver to the more modern SDN stack of OVN - in place. With all existing user networks, subnets, security groups and (running) instances in the database already. And while I know there a push of migrating from OVS to OVN and a clear migration path documented (https://docs.openstack.org/neutron/latest/ovn/migration.html) but they are much more similar in their data plane. And to get this out of the way: I am not asking to do be able to do this without downtime, interruptions, migrations or any active orchestration of the process. I just want to know all the possible options apart from setting up a new cloud and asking folks to migrate all of their things over... 1) Are the data models of the user managed resources abstract (enough) from the ML2 used? So would the composition of a router, a network, some subnets, a few security group and a few instances in a project just result in a different instantiation of packet handling components, but be otherwise transparent to the user? 2) What could be possible migration strategies? While it might be a little early to think about the actual migration steps. But just to consider more than a full cloud shutdown following a cold start with modified neutron config then using the OVN ML2. I know there is more than just the network and getting a virtual layer 2 network. There are DHCP, DNS and the metadata service and last but not least the gateway / router and the security groups. But if using VXLAN for OVN (as Linuxbridge uses currently) could the shift from one implementation to the other potentially be done node by node? Or project by project by changing the network agents over to nodes already running OVN? If not, is there any other hot cut-over approach that would avoid having to shutdown all the instances, but only cause them some network downtime (until the next DHCP renew or similar?) Has anybody ever done something similar or heard about this being done anywhere? Thanks for your time and input, Christian

3 5

[all][tc] What's happening in Technical Committee: summary 2022 Nov 25: Reading: 5 min
by Ghanshyam Mann 25 Nov '22

25 Nov '22

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ *This week's meeting was cancelled. * Next TC weekly meeting will be on Nov 30 Wed at 16:00 UTC. Feel free to add the topic to the agenda[1] by Nov 29. 2. What we completed this week: ========================= * Nothing specific this week. 3. Activities In progress: ================== TC Tracker for 2023.1 cycle --------------------------------- * Current cycle working items and their progress are present in 2023.1 tracker etherpad[2]. Open Reviews ----------------- * Five open reviews for ongoing activities[3]. Technical Election changes (Extending Nomination and voting period) ---------------------------------------------------------------------------------- As discussed in TC PTG sessions, TC is extending the technical election (PTL as well as the TC election) nomination and voting period from 1 week to 2 weeks. The TC charter change[4] is up for review and the changes will be effective from the 2023.2 cycle technical elections. Renovate translation SIG i18 ---------------------------------- * As the next step, Brian is working on the weblate funding proposal and it will be discussed with the Foundation staff and Board members in Dec 6th board meeting. Adjutant situation (project is not active) ----------------------------------------------- The adjutant project is not active. The last changes merged was on Oct 26, 2021 (more than 1 year back), Gate is broken also. During July this year, TC was marking this project as inactive[5] but Dale smith volunteered as PTL to maintain it. But there is no improvement in the situation yet. TC will be discussing it in the next TC meeting and decide the next step. Project updates ------------------- * Add Skyline repository for OpenStack-Ansible[6] * Add the cinder-infinidat charm to Openstack charms[7] * Add the infinidat-tools subordinate charm to OpenStack charms[8] * Add the manila-infinidat charm to Openstack charms[9] 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[10]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15:00 UTC [11] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://lists.openstack.org/pipermail/openstack-discuss/2022-November/03124… [2] https://etherpad.opendev.org/p/tc-2023.1-tracker [3] https://review.opendev.org/q/projects:openstack/governance+status:open [4] https://review.opendev.org/c/openstack/governance/+/865367 [5] https://review.opendev.org/c/openstack/governance/+/849153 [6] https://review.opendev.org/c/openstack/governance/+/863166 [7] https://review.opendev.org/c/openstack/governance/+/863958 [8] https://review.opendev.org/c/openstack/governance/+/864067 [9] https://review.opendev.org/c/openstack/governance/+/864068 [10] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [11] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann

1 0

[all][stable][ptl] Propose to EOL Queens series
by Elõd Illés 25 Nov '22

25 Nov '22

Hi, As more and more teams decide about moving their Queens branches to End of Life, it looks like the time has come to transition the complete Queens stable release for every project. The reasons behind this are the following things: - gates are mostly broken - minimal number of bugfix backports are pushed to these branches - gate job definitions are still using the old, legacy zuul syntax - gate jobs are based on Ubuntu Xenial, which is also beyond its public maintenance window date and hard to maintain - lack of reviews / reviewers on this branch Based on the above, if no objection comes from teams, then I'll start the process of EOL'ing Queens stable series. Please let the community know what you think, or indicate if any of the projects' stable/queens branch should be kept open in Extended Maintenance. Thanks, Előd Illés irc: elodilles @ #openstack-stable / #openstack-release

1 1