ovnkube.sh resets all permissions in /run/openvswitch to root:root by default #1982
Comments
|
@thywyn I think the issue with current approach to expand the scope is, we don't really sure who gets to redeploy the last, and if ovn gets to redeploy, the permission will still bind to root:root. |
yaguangtang
added a commit
that referenced
this issue
Oct 28, 2024
…cess update ovn-controler script to chown ovs bridge socket files so that libvirt pod can read fix #1982
yaguangtang
added a commit
that referenced
this issue
Oct 28, 2024
…cess update ovn-controler script to chown ovs bridge socket files so that libvirt pod can read fix #1982
yaguangtang
added a commit
that referenced
this issue
Oct 29, 2024
…cess update ovn-controler script to chown ovs bridge socket files so that libvirt pod can read fix #1982
|
Hey, I see that the the image is fixed.. When are you all adding the environment variable to the daemonset? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We are running into issues where the /run/openvswitch/ directory is getting reset to root:root after ovn-controller pods runs in the ovnkube.sh startup script. neuton-ovn-metadata-agent init scripts only resets the control and socket files back to 42424:42424.. So, VMs building with DPDK interfaces fail with errors like the following "libvirt.libvirtError: internal error: process exited while connecting to monitor: 2024-10-14T14:30:53.518766Z qemu-system-x86_64: -chardev socket,id=charnet0,path=/var/run/openvswitch/vhua820f710-65,server=on: Failed to bind socket to /var/run/openvswitch/vhua820f710-65: Permission denied"
ovn-controller pods do have an environment variable that could be used "OVS_USER_ID=...." but the 42424 user is not defined on the container. Without rebuilding the container with that user, the only other way I can think of is to expand the scope of the chown that neuton-ovn-metadata-agent init scripts does.
The text was updated successfully, but these errors were encountered: