On 06/05/2025 07:11, davorin.mikulic@gmail.com wrote:
Hello Brian,
Thanks for your answer.
The thing is that I need Wallaby because of compatibility with the specific version of Openshift (v4.17) which I would like to deploy on top of Openstack.
so to answer brian's question about tripleo, the last release it supported was Zed so there are no upstream release that are still supported that were supported by tripleo. if openshift cares or even really i know what version of openstack is deploy such that using a later version would break the integration you should report those issues as a bug because it should be forwards compatible.
I also suspected that privsep is not configured properly but based on the line in the log: 2025-05-05 13:22:40.180 226859 INFO oslo.privsep.daemon [-] privsep process running with capabilities (eff/prm/inh): CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_NET_ADMIN|CAP_SYS_ADMIN/CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_NET_ADMIN|CAP_SYS_ADMIN/none it is supposed to have SYS_ADMIN privileges which should allow for the modification of the interface. I also tried explicitly passing SYS_ADMIN privileges through [privsep] part of neutron.conf but the result was the same.
i don't think the capabilities are configure able via the neutron config. that questionable if they are configurable form a security point of view. the config is only intened to allow you to chagne if the deamon is pre-spanwed and or the binary to use to spawn it in general.
No other operations are failing similarly.
im not inclined to think this is a privsep issue but i have 2 guesses/suggestion about where to look 1 its related to the binary comaptiblity between the package in the contier and teh host kernel (less likely since it worked when you exected in) 2 its an issue with selinux. 3 your kernel or ovs version does not supprot a feature its trying to enable the operation not supported issue can happen if your using a incompatible iptables binary i belive (i dont know the full deatils) that depend on teh version of centos/rhel you have deploy the legacy iptables model or the newer nftabls module can be used as a backend if the tool in the tool in the container is expecting nftables but your kernel is using legacy iptable then you can get not supprot errors i belive. beyond that the kernel ioctl interface can chagne between kernel version and gcc versions so sometime you need to bind mount the host binary or use a continer build with the host os to get it to alingn. i.e. the ip tools binary in teh contaner can be incompatible with the host kernel because the ioctl abi depend on the kernel headers and gcc version used to compile it. downstream our wallaby based release OSP (17.1) was support on rhel 8 during upgrades form train and rhel 9.2 for its main OS durign the full lifecycle. i think if you try to run the rhel8 version of the contienr on rhel9 without bind mounting it can fail like this? im not an expert on that and its been a few years since i looked at this so take that with a grain or salt. so for option 1 have you confirm the the container is built for the same Major version of the OS as its running on? you mentioned doing an exec into the container as root and it worked which implies they are aligned but good to check that in anycase. i have not looked at the code specifically but form the backtrace it looks liek its trying to delete an ip address so i assume its going to invoke the equivelent of `ip a del <ip addres> dev <interface>` although perhaps via the iproute2 python lib instead fo the shell. the iproute2 python package has the same ABI compatibility issues as the cli tools the fact the back trace has py3.6 implies its a centos 8 container since centos 9 would use 3.9. the other common issue is selinux, i would check the audit logs if you installed the systemd-container package that can also impact how selinux is applied to the comamnd in the contaienr in some cases due to changes in the behvior of podman and libvirt. if it was selinux or a general privsep issue i would have expected a permission denieed error instead of operation not supported. so that is less likely which is why i listed it second increasingly unlikely is that your kernel or ovs version does not supprot deleteing an ip adress form an interface. The only way i can think of that realisticly happening is if you disabled ipv4 or ipv6 on this host but neutron was still trying to use it. Operation not supproted might be a reasonable respoce if you tried to delete an ipv6 adress on a host that has ipv6 disabled on all interfaces for example. im not sure if any of the 3 options above are you actuall problem but those are 3 thing i would rule out first before assumeing its privsep related.
Best regards, Davorin