October 2023 - openstack-discuss - lists.openstack.org

[keystone] Weekly Meeting 11/1 Canceled
by Dave Wilde 27 Oct '23

27 Oct '23

Hello all, I'm on PTO the week of 11/1 so I'm canceling the Weekly meeting as well as the reviewathon on 11/3. Thanks! /Dave

1 0

[vPTG][Security SIG] Agenda / Planning etherpad
by Tony Breeds 27 Oct '23

27 Oct '23

Hello All, I'ms sorry for getting this out with so little notice. I've pulled together an agenda for the os-security SIG meeting at the vPTG When: https://www.timeanddate.com/worldclock/fixedtime.html?iso=2023-10-27T16:00:… Where: https://meetpad.opendev.org/oct2023-ptg-os-security Planning Etherpad: https://etherpad.opendev.org/p/oct2023-ptg-os-security Agenda: * Previous PTGs carryover ** https://etherpad.opendev.org/p/vancouver-june2023-os-security-sig *** Xstatic --https://review.opendev.org/c/openstack/xstatic-jquery-migrate/+/878923 ** https://etherpad.opendev.org/p/march2023-ptg-os-security *** image encryption pop-up team (Luzi) **** castellan consumers api is in place now, unblocking significant parts of the implementation * Should we meet outside of the PTG events [10 mins] * https://security.openstack.org/ Updates ** Sorting of OSSNs -- Something along the lines of -- https://review.opendev.org/c/openstack/releases/+/887691 ** Remove references to storyboard? * Other business? * VMT Business * Open public security bug triage/processing -- http://tiny.cc/public-ossn Yours Tony.

1 0

[glance][ops] FEEDBACK REQUEST: Deprecating VMWare Datastore store driver
by Takashi Kajinami 26 Oct '23

26 Oct '23

Hello, In glance_store we have maintained the VMWare Datastore store driver which stores image data in ESX/ESXi or vCenter Server. This store driver was added 9 years ago[1] to be used in the VMware environment with OpenStack. However now the vmwarapi virt driver was marked experimental and is being removed from nova[2], so it seems the original use case is no longer valid. I proposed deprecating this store driver during this cycle[3], so that we can remove it during D (or E) cycle, but I'm sending this email to gather early feedback before we merge the deprecation. In case if you are using the driver or have any concern, please reply to me (publicly or privately) or leave your comments in the review. [1] https://review.opendev.org/c/openstack/glance/+/58883 [2] https://review.opendev.org/c/openstack/nova/+/897017 [3] https://review.opendev.org/c/openstack/glance_store/+/893696 Thank you, Takashi

1 0

[neutron][openvswitch][antelope] Bridge eth1 for physical network provider does not exist
by ddorra＠t-online.de 26 Oct '23

26 Oct '23

Hello, I'm installing Openstack Antelope with network option 2 ( following https://docs.openstack.org/neutron/2023.2/install/compute-install-option2-u…) The interface name of the provider network is eth1, so I put this to bridge_mappings. The local IP is from the management network. #------------------------------------------------------ # /etc/neutron/plugins/ml2/openvswitch_agent.ini # [DEFAULT] [agent] [dhcp] [network_log] [ovs] bridge_mappings = provider:eth1 [securitygroup] enable_security_group = true firewall_driver = openvswitch [vxlan] local_ip = 192.168.2.71 l2_population = true #-------------------------------------------------------- However, the neutron log complains that bridger eth1 does not exist. Launching of instances fails neutron-openvswitch-agent.log: 2023-10-23 19:26:00.062 17604 INFO os_ken.base.app_manager [-] instantiating app os_ken.app.ofctl.service of OfctlService 2023-10-23 19:26:00.062 17604 INFO neutron.agent.agent_extensions_manager [-] Loaded agent extensions: [] 2023-10-23 19:26:00.108 17604 INFO neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_bridge [-] Bridge br-int has datapath-ID 00005e65b1943a49 2023-10-23 19:26:02.438 17604 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [-] Mapping physical network provider to bridge eth1 vvvvvvv 2023-10-23 19:26:02.438 17604 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [-] Bridge eth1 for physical network provider does not exist. Agent terminated! ^^^^^^^ 2023-10-23 19:26:03.914 17619 INFO neutron.common.config [-] Logging enabled! 2023-10-23 19:26:03.914 17619 INFO neutron.common.config [-] /usr/bin/neutron-openvswitch-agent version 20.4.0 2023-10-23 19:26:03.914 17619 INFO os_ken.base.app_manager [-] loading app neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_oskenapp ----------------------------------------- Additional information root@control:/var/log/neutron# openstack network list +--------------------------------------+----------+--------------------------------------+ | ID | Name | Subnets | +--------------------------------------+----------+--------------------------------------+ | 32f53edc-a394-419f-a438-a664183ee618 | doznet | e38e25c2-4683-48fb-a7a0-7cbd7d276ee1 | | 74e3ee6a-1116-4ff6-9e99-530c3cbaef28 | provider | 2d3c3de4-9a0d-4a21-9af1-8ecb9f6f16d5 | +--------------------------------------+----------+--------------------------------------+ root@control:/var/log/neutron# root@compute1:/etc/neutron/plugins/ml2# ip a 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 08:00:27:9f:c7:89 brd ff:ff:ff:ff:ff:ff inet 192.168.2.71/24 brd 192.168.2.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::a00:27ff:fe9f:c789/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 08:00:27:91:60:58 brd ff:ff:ff:ff:ff:ff inet 10.0.0.71/24 brd 10.0.0.255 scope global eth1 valid_lft forever preferred_lft forever inet6 fe80::a00:27ff:fe91:6058/64 scope link valid_lft forever preferred_lft forever 4: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether da:3b:3a:a0:59:97 brd ff:ff:ff:ff:ff:ff 5: br-int: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:65:b1:94:3a:49 brd ff:ff:ff:ff:ff:ff 6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:53:87:59 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever What are the proper settings? Any help appreciated Dieter

4 5

[oslo] oslo-rootwrap daemon test failures
by Chuck Tuffli 26 Oct '23

26 Oct '23

There are a handful of failures when running the oslo-rootwrap test suite on FreeBSD. Most I have been able to fix, but I'm looking for some help understanding what is going wrong with the daemon tests. One example of a failing test is test_daemon_cleanup_client. The test reports: AssertionError: -9 == -9 : Server haven't stopped in one second which I _think_ occurs because of an exception while closing the connection (see below). Any suggestions as to what I might check (and where) to understand why this is happening? Thanks! Running the latest from git on FreeBSD 13.2 with Python 3.9 {2} oslo_rootwrap.tests.test_functional.RootwrapDaemonTest.test_daemon_cleanup_client [1.455829s] ... FAILED Captured traceback: ~~~~~~~~~~~~~~~~~~~ Traceback (most recent call last): File "/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/oslo_rootwrap/tests/test_functional.py", line 299, in test_daemon_cleanup_client self.client._finalize() File "/usr/local/lib/python3.9/contextlib.py", line 126, in __exit__ next(self.gen) File "/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/oslo_rootwrap/tests/test_functional.py", line 289, in _test_daemon_cleanup self.assertNotEqual(-signal.SIGKILL, process.returncode, File "/usr/local/lib/python3.9/unittest/case.py", line 846, in assertNotEqual raise self.failureException(msg) AssertionError: -9 == -9 : Server haven't stopped in one second Captured daemon_log: ~~~~~~~~~~~~~~~~~~~~ 2023-10-19 18:33:10,718 | [ 1664]+DEBUG | Created temporary directory /tmp/rootwrap-snf7oiau 2023-10-19 18:33:10,718 | [ 1664]+DEBUG | Will listen on socket /tmp/rootwrap-snf7oiau/rootwrap.sock 2023-10-19 18:33:10,719 | [ 1664]+ INFO | Starting rootwrap daemon main loop 2023-10-19 18:33:11,719 | [ 1664]+ INFO | Got signal 2. Shutting down server 2023-10-19 18:33:11,719 | [ 1664]+DEBUG | Removing temporary directory /tmp/rootwrap-snf7oiau Traceback (most recent call last): File "/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/.tox/py3/lib/python3.9/site-packages/oslo_rootwrap/daemon.py", line 166, in daemon_start server.serve_forever() File "/usr/local/lib/python3.9/multiprocessing/managers.py", line 184, in serve_forever sys.exit(0) SystemExit: 0 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/oslo_rootwrap/tests/run_daemon.py", line 58, in <module> cmd.daemon() File "/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/.tox/py3/lib/python3.9/site-packages/oslo_rootwrap/cmd.py", line 62, in daemon return main(run_daemon=True) File "/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/.tox/py3/lib/python3.9/site-packages/oslo_rootwrap/cmd.py", line 133, in main daemon_mod.daemon_start(config, filters) File "/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/.tox/py3/lib/python3.9/site-packages/oslo_rootwrap/daemon.py", line 171, in daemon_start conn.close() File "/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/.tox/py3/lib/python3.9/site-packages/oslo_rootwrap/jsonrpc.py", line 92, in close self._socket.shutdown(socket.SHUT_RDWR) OSError: [Errno 57] Socket is not connected Captured client_log: ~~~~~~~~~~~~~~~~~~~~ 2023-10-19 18:33:10,290 | [ 1610] DEBUG | Popen for ['/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/.tox/py3/bin/python', '/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/oslo_rootwrap/tests/run_daemon.py', '/tmp/tmpjri8_7we/rootwrap.conf'] command has been instantiated 2023-10-19 18:33:10,719 | [ 1610] INFO | Spawned new rootwrap daemon process with pid=1664 2023-10-19 18:33:10,728 | [ 1610] INFO | Stopping rootwrap daemon process with pid=1664 2023-10-19 18:33:11,733 | [ 1610] INFO | Rootwrap daemon process exit with status: -9

3 4

[CloudKitty] Cancelling weekly meeting 30 of October
by Rafael Weingärtner 25 Oct '23

25 Oct '23

Hello guys, As we discussed in the vPTG, we will be cancelling the next CloudKitty bi-weekly meeting that would take place on October the 30. If you need any assistance until the next meeting, you can reach me via e-mail. Best regards, -- Rafael Weingärtner

1 0

[manila] Oct 26th upstream meeting is cancelled
by Carlos Silva 25 Oct '23

25 Oct '23

Hello everyone! Cancelling this week's upstream meeting as we will be focused on the OpenStack Manila PTG [1]. Next meeting will take place on Nov 2nd. [1] https://etherpad.opendev.org/p/caracal-ptg-manila Thanks, carloss

1 0

[cinder] Cancelling this week's meeting (25 Oct)
by Rajat Dhasmana 25 Oct '23

25 Oct '23

Hello Argonauts, We have the 2024.1 Caracal PTG this week so cancelling the upstream meeting. See you at the PTG! Dates: 24 October (Tuesday) - 27 October (Friday), 2023 Time: 1300 - 1700 UTC Room: Cactus Meeting Link: https://www.openstack.org/ptg/rooms/cactus Thanks Rajat Dhasmana

1 0

[neutron][octavia] New deployment / suggestions for network
by Eric K. Miller 24 Oct '23

24 Oct '23

Hi, We have been deploying OpenStack for quite some time, using Kolla-Ansible, and typically choose DVR and OVS with Amphorae deployed by Octavia for load balancing. With the issues that DVR has with Octavia's Amphorae and Virtual IPs, with essentially non-functional automated fail-over, we have always wanted to move to OVN since it appears to be the popular approach now. I have also read that OVN appears to work properly with allowed-address-pairs correctly, whereas with DVR, OVS does not, and thus some of the issues with Amphorae Virtual IPs. However, OVN, from what I understand, has issues with, or doesn't support, VPNaaS, which we use extensively. Plus, it only supports Layer 4 load balancing, whereas with Amphorae, we get Layer 7 load balancing - also used extensively. I'm not sure, though - maybe OVN with Octavia still supports Amphorae if we need Layer 7 load balancing? Am I wrong regarding any of the comments above? What is the best back-end networking architecture that provides scalability (so, not VLANs), Layer 7 load balancing with Octavia, along with VPNaaS, in a brand new install with the latest version of OpenStack? Note that we used Midonet long long ago, and it seemed to have everything we wanted, but shortly after purchasing it, Midokura immediately decided to abandon support for OpenStack and went the Kubernetes route. Not sure if they still do this, but needless to say, Midonet isn't a valid solution unfortunately. Tungsten Fabric appears like an alternate solution to Midonet, but that project is sunsetting in 2024, so that's dead too. :( Thank you for any suggestions! Eric

4 6

[kolla] Cancelling weekly meeting tomorrow (25th Oct 2023)
by Michał Nasiadka 24 Oct '23

24 Oct '23

Hello, Cancelling tomorrows weekly meeting since we’re already meeting at vPTG sessions. Thanks, Michal

1 0