April 2023 - openstack-discuss - lists.openstack.org

[ptl] Need PTL volunteer for OpenStack Vitrage
by Ghanshyam Mann 11 Jul '23

11 Jul '23

Hi Eyal, I am reaching out to you as you were PTL for OpenStack Vitrage project in the last cycle. There is no PTL candidate for the next cycle (2023.2), and it is on the leaderless project list. Please check if you or anyone you know would like to lead this project. - https://etherpad.opendev.org/p/2023.2-leaderless Also, if anyone else would like to help leading this project, this is time to let TC knows. -gmann

3 3

Experience with VGPUs
by Oliver Weinmann 22 Jun '23

22 Jun '23

Dear All, we are planning to have a POC on VGPUs in our Openstack cluster. Therefore I have a few questions and generally wanted to ask how well VGPUs are supported in Openstack. The docs, in particular: https://docs.openstack.org/nova/zed/admin/virtual-gpu.html explain quite well the general implementation. But I am more interested in general experience with using VGPUs in Openstack. We currently have a small YOGA cluster, planning to upgrade to Zed soon, with a couple of compute nodes. Currently our users use consumer cards like RTX 3050/3060 on their laptops and the idea would be to provide VGPUs to these users. For this I would like to make a very small POC where we first equip one compute node with an Nvidia GPU. Gladly also a few tips on which card would be a good starting point are highly appreciated. I know this heavily depends on the server hardware but this is something I can figure out later. Also do we need additional software licenses to run this? I saw this very nice presentation from CERN on VGPUs: https://indico.cern.ch/event/776411/contributions/3345183/attachments/18516… In the table they are listing Quadro vDWS licenses. I assume we need these in order to use the cards? Also do we need something like Cyborg for this or is VGPU fully implemented in Nova? Best Regards, Oliver

17 36

[ironic] ARM Support in CI: Call for vendors / contributors / interested parties
by Jay Faulkner 15 Jun '23

15 Jun '23

Hi stackers, Ironic has published an experimental Ironic Python Agent image for ARM64 ( https://tarballs.opendev.org/openstack/ironic-python-agent-builder/dib/file…) and discussed promoting this image to supported via CI testing. However, we have a problem: there are no Ironic developers with easy access to ARM hardware at the moment, and no Ironic developers with free time to commit to improving our support of ARM hardware. So we're putting out a call for help: - If you're a hardware vendor and want your ARM hardware supported? Please come talk to the Ironic community about setting up third-party-CI. - Are you an operator or contributor from a company invested in ARM bare metal? Please come join the Ironic community to help us build this support. Thanks, Jay Faulkner Ironic PTL

6 11

[storlets] Proposal to make Train/Ussuri/Victoria EOL
by Takashi Kajinami 14 Jun '23

14 Jun '23

Hello, Currently we have multiple stable branches open but we haven't seen any backport proposed so far. To reduce number of branches we have to maintain, I'd like to propose retiring old stable branches(train, ussuri and victoria). In case you have any concerns, please let me know. Thank you, Takashi Kajinami

1 1

Kubernetes Conformance 1.24 + 1.25
by Kendall Nelson 06 Jun '23

06 Jun '23

Hello All! First of all, I want to say a huge thanks to Guilherme Steinmuller for all his help ensuring that OpenStack Magnum remains Kubernetes Certified [1]! We are certified for v1.24! However, in digging into the set of conformance tests this round, it appears that we will not be able to get 1.25 certified with the current Magnum. This means that in May when we have to re-cert (every 3 months they reach an EOL because that's k8s release cadence) we will not be able to maintain this which is the other part of why I wanted to write this email - to raise awareness and ask for help digging into what needs to happen to make sure we can retain this. Tangentially related, Guilherme has posted a patch with documentation for how to run the conformance tests for yourself and it could use some reviews [2]. And one last thing, I have begun conversation with the opendev folks about what it might take to setup jobs to run the conformance tests periodically so that we don't have to manually run them when it's time to recert. I am planning on submitting a forum topic for this for those interested :) Long live LOKI! - Kendall Nelson [1] https://github.com/cncf/k8s-conformance/pull/2446 [2] https://review.opendev.org/c/openstack/magnum/+/849156

5 10

[ironic][stable] Proposing EOL of ironic project branches older than Wallaby
by Jay Faulkner 02 Jun '23

02 Jun '23

Hi all, Ironic has a large amount of stable branches still in EM. We need to take action to ensure those branches are either retired or have CI repaired to the point of being usable. Specifically, I'm looking at these branches across all Ironic projects: - stable/queens - stable/rocky - stable/stein - stable/train - stable/ussuri - stable/victoria In lieu of any volunteers to maintain the CI, my recommendation for all the branches listed above is that they be marked EOL. If someone wants to volunteer to maintain CI for those branches, they can propose one of the below paths be taken instead: 1 - Someone volunteers to maintain these branches, and also report the status of CI of these older branches periodically on the Ironic whiteboard and in Ironic meetings. If you feel strongly that one of these branches needs to continue to be in service; volunteering in this way is how to save them. 2 - We seriously reduce CI. Basically removing all tempest tests to ensure that CI remains reliable and able to merge emergency or security fixes when needed. In some cases; this still requires CI fixes as some older inspector branches are failing *installing packages* in unit tests. I would still like, in this case, that someone volunteers to ensure the minimalist CI remains happy. My intention is to let this message serve as notice and a waiting period; and if I've not heard any response here or in Monday's Ironic meeting (in 6 days), I will begin taking action on retiring these branches. This is simply a start; other branches (including bugfix branches) are also in bad shape in CI, but getting these retired will significantly reduce the surface area of projects and branches to evaluate. I know it's painful to drop support for these branches; but we've provided good EM support for these branches for a long time and by pruning them away, we'll be able to save time to dedicate to other items. Thanks, Jay Faulkner

3 5

[Cinder][LVM backend] LVM vg backed by a shared LUN
by wodel youchi 31 May '23

31 May '23

Hi, The examples I could find on the internet using LVM as backend for Cinder, they expose a local disk using lvm via Cinder. I did this configuration and I am wondering if it's correct, especially from a "simultaneous access" point of view. I have an iSCSI target backed by targetcli that exposes a LUN to my compute nodes. I did configure the iscsi connexion manually on each one of them and they all see the LUN, then on one of them I created the cinder-volumes VG (the other nodes can see the modifications), then I configured Cinder with lvm backend using this VG and it worked. I created some volumes on it without issues using my account. But what about when there are multiple tenants that try to create multiple volumes on it, is this configuration safe? Regards.

3 2

[cinder] - Test cases or procedure for active/active support validation
by Roquesalane, Jean-Pierre 30 May '23

30 May '23

Hi community! Here at Dell, we're in the process of certifying our Dell PowerMax storage platform against cinder volume Active/active configuration. I was wondering how vendors who already support this functionality have managed to handle this and if they can share their testing scenario. Thank you. JP Jean-Pierre Roquesalane SW System Sr Principal Engineer - OpenStack Champion Dell Technologies | Security and Ecosystem Software Mobile +33 6 21 86 79 04<tel:1-613-314-8106> Email : jeanpierre.roquesalane(a)dell.com<mailto:jeanpierre.roquesalane@dell.com> [cid:image001.png@01D976C9.D5B91180] Internal Use - Confidential Dell S.A, Si?ge Social 1 rond point Benjamin Franklin 34000 Montpellier. Capital 1,782,769 Euros, 351 528 229 RCS Montpellier -APE 4651Z -TVA Intracommunautaire FR 20 351 528 229, SIRET 351 528 229 00088 Vat Number : FR 20351528229 (France) / IT00001709997 (Italy) / ESN0012622G (Spain)

2 1

[kolla-ansible][yoga] Does glance support cinder-nfs as backend?
by wodel youchi 30 May '23

30 May '23

Hi, The openstak documentation says that glance supports cinder as backend, but it does not exclude any backend used by cinder itself. I'm having trouble configuring glance to use a cinder backend which is backed by an nfs share. Is this configuration supported? First, the rootwrap was missing, after adding it, I faced the lack of privileges, which was corrected by starting the glance-api container in privileged mode and finally I am facing a non existing filter error. Glance is trying to mount the nfs share to use it!!! Which I don't understand , why mount a share that is already mounted by cinder which glance is supposed to use as an intermediary!!!? When I push an image I get this error: Stderr: '/var/lib/kolla/venv/bin/glance-rootwrap: Unauthorized command: mount -t nfs 20.1.0.32:/kolla_nfs /var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624 f97bf3623b13014f22186b7 (no filter matched)\n' Regards.

3 3

[kolla-ansible][yoga] Glance backend cinder Privsep daemon failed to start operation not permitted
by wodel youchi 30 May '23

30 May '23

Hi, I am trying to configure glance to use cinder as a backend. This is my glance-api.conf [cinder] cinder_store_auth_address = https://dashint.example.com:5000/v3 cinder_store_user_name = cinder cinder_store_password = cinderpass cinder_store_project_name = service cinder_volume_type = nfstype rootwrap_config = /etc/glance/rootwrap.conf ==> /var/log/kolla/glance/glance-api.log <== > 2023-04-12 18:02:20.842 64 INFO oslo.privsep.daemon > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4 > b0f76b5c6dcb457fa716762bbf954837 - default default] Spawned new privsep > daemon via rootwrap > 2023-04-12 18:02:20.733 360 INFO oslo.privsep.daemon [-] privsep daemon > starting > 2023-04-12 18:02:20.735 360 INFO oslo.privsep.daemon [-] privsep process > running with uid/gid: 0/0 > > *2023-04-12 18:02:20.737 360 ERROR oslo.privsep.daemon [-] [Errno 1] > Operation not permitted Traceback (most recent call last): * > File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", > line 584, in helper_main > Daemon(channel, context).run() > File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", > line 394, in run > self._drop_privs() > File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", > line 430, in _drop_privs > capabilities.drop_all_caps_except(self.caps, self.caps, []) > File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/capabilities.py", > line 156, in drop_all_caps_except > raise OSError(errno, os.strerror(errno)) > PermissionError: [Errno 1] Operation not permitted > 2023-04-12 18:02:20.844 64 WARNING oslo_privsep.comm > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4 > b0f76b5c6dcb457fa716762bbf954837 - default > default] Unexpected error: <class 'BrokenPipeError'>: BrokenPipeError: > [Errno 32] Broken pipe > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4 > b0f76b5c6dcb457fa716762bbf954837 - default > default] Error while sending initial PING to privsep: [Errno 32] Broken > pipe: BrokenPipeError: [Errno 32] Broken pipe > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon Traceback (most > recent call last): > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", > line 192, in exchange_ping > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon reply = > self.send_recv((comm.Message.PING.value,)) > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/comm.py", > line 186, in send_recv > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon > self.writer.send((myid, msg)) > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/comm.py", > line 60, in send > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon > self.writesock.sendall(buf) > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon File > "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/greenio/base.py", > line 407, in sendall > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon tail = > self.send(data, flags) > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon File > "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/greenio/base.py", > line 401, in send > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon return > self._send_loop(self.fd.send, data, flags) > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon File > "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/greenio/base.py", > line 388, in _send_loop > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon return > send_method(data, *args) > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon BrokenPipeError: > [Errno 32] Broken pipe > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon > 2023-04-12 18:02:20.846 64 CRITICAL oslo.privsep.daemon > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4 > b0f76b5c6dcb457fa716762bbf954837 - defau > lt default] Privsep daemon failed to start > 2023-04-12 18:02:20.847 64 ERROR glance_store._drivers.cinder > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4 > b0f76b5c6dcb457fa716762bbf954837 - > default default] Failed to write to volume > 46316c12-6c24-40af-afde-1c16edd616b6.: > oslo_privsep.daemon.FailedToDropPrivileges: Privsep daemon failed to start > 2023-04-12 18:02:20.890 64 ERROR glance.api.v2.image_data > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4 > b0f76b5c6dcb457fa716762bbf954837 - def > ault default] *Failed to upload image data due to internal error: > oslo_privsep.daemon.FailedToDropPrivileges: Privsep daemon failed to start * > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4 > b0f76b5c6dcb457fa716762bbf954837 - default d > efault] Caught error: Privsep daemon failed to start: > oslo_privsep.daemon.FailedToDropPrivileges: Privsep daemon failed to start > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi Traceback (most recent > call last): > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/wsgi.py", > line 1332, in __call__ > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi request, > **action_args) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/wsgi.py", > line 1370, in dispatch > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi return > method(*args, **kwargs) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/utils.py", > line 414, in wrapped > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi return func(self, > req, *args, **kwargs) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/api/v2/image_data.py", > line 303, in upload > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > self._restore(image_repo, image) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > line 227, in __exit__ > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > self.force_reraise() > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > line 200, in force_reraise > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi raise self.value > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/api/v2/image_data.py", > line 163, in upload > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > image.set_data(data, size, backend=backend) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/notifier.py", line > 497, in set_data > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > _send_notification(notify_error, 'image.upload', msg) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > line 227, in __exit__ > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > self.force_reraise() > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > line 200, in force_reraise > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi raise self.value > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/notifier.py", line > 444, in set_data > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > set_active=set_active) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/quota/__init__.py", > line 323, in set_data > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > set_active=set_active) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/location.py", line > 585, in set_data > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > self._upload_to_store(data, verifier, backend, size) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/location.py", line > 485, in _upload_to_store > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi verifier=verifier) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/multi_backend.py", > line 399, in add_with_multihash > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi image_id, data, > size, hashing_algo, store, context, verifier) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/multi_backend.py", > line 481, in store_add_to_backe > nd_with_multihash > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi image_id, data, > size, hashing_algo, context=context, verifier=verifier) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/driver.py", > line 279, in add_adapter > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi metadata_dict) = > store_add_fun(*args, **kwargs) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/capabilities.py", > line 176, in op_checker > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi return > store_op_fun(store, *args, **kwargs) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py", > line 985, in add > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi with > self._open_cinder_volume(client, volume, 'wb') as f: > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/usr/lib64/python3.6/contextlib.py", line 81, in __enter__ > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi return > next(self.gen) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py", > line 739, in _open_cinder_vol > ume > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi root_helper, > my_ip, use_multipath, enforce_multipath, host=host) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/utils.py", line > 169, in trace_logging_wrapper > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi return f(*args, > **kwargs) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/initiator/connector.py", > line 240, in get_connector_pr > operties > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi execute=execute)) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py", > line 70, in get_connec > tor_properties > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi initiator = > iscsi.get_initiator() > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py", > line 963, in get_initi > ator > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > root_helper=self._root_helper) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/executor.py", > line 53, in _execute > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi result = > self.__execute(*args, **kwargs) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/privileged/rootwrap.py", > line 172, in execute > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi return > execute_root(*cmd, **kwargs) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/priv_context.py", > line 269, in _wrap > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi self.start() > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/priv_context.py", > line 283, in start > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi channel = > daemon.RootwrapClientChannel(context=self) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", > line 374, in __init__ > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > super(RootwrapClientChannel, self).__init__(sock, context) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", > line 187, in __init__ > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > self.exchange_ping() > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", > line 201, in exchange_ping > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi raise > FailedToDropPrivileges(msg) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi *oslo_privsep.daemon.FailedToDropPrivileges: > Privsep daemon failed to start * > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > 2023-04-12 18:02:20.927 64 INFO eventlet.wsgi.server > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4 > b0f76b5c6dcb457fa716762bbf954837 - default > default] 20.3.0.34,127.0.0.1 - - [12/Apr/2023 18:02:20] "PUT > /v2/images/52ed7ed7-330e-4249-abb9-5ec99712846f/file HTTP/1.1" 500 430 > 2.727683 > It seems like a lack of privileges, any ideas? Regards.

4 11