Adding clarification about what we (DFG:Upgrade) understand about the resolution of this bz: ovs-2.9 is coming and it need to have directory permission adjusted for log rotation to work. So /var/log/openvswitch should belongs to openvswitch:openvswitch, not root:root To add a twist, if dpdk is added (but is that expected on ops10 ?) then we need: - add hugelbfs group to openvswitch user - change the directory to openvswitch:hugetlbfs The first one (no dpdk) seems simple enough to fix during upgrade, the second part would need clarification. I'm unclear about the how we test the %ifarch %{dpdkarches} in a script thoug. This should go into osp9-10 upgrade and into osp10 minor update.
Note for FFU scenario (after OSP10 minor update and reboot of the nodes): [root@controller-1 heat-admin]# ls -ld /var/log/openvswitch/ drwxr-x---. 2 openvswitch hugetlbfs 54 May 30 13:59 /var/log/openvswitch/ [root@controller-1 heat-admin]# ls -l /var/log/openvswitch/ total 48 -rw-r-----. 1 openvswitch hugetlbfs 720 Jun 26 22:07 ovsdb-server.log -rw-r-----. 1 openvswitch hugetlbfs 42526 Jun 26 22:09 ovs-vswitchd.log [root@controller-1 heat-admin]# rpm -q openvswitch openvswitch-2.9.0-19.el7fdp.1.x86_64 [root@controller-1 heat-admin]# cat /etc/rhosp-release Red Hat OpenStack Platform release 10.0 (Newton) [root@compute-0 heat-admin]# ls -ld /var/log/openvswitch/ drwxr-x---. 2 openvswitch hugetlbfs 54 May 30 13:59 /var/log/openvswitch/ [root@compute-0 heat-admin]# ls -l /var/log/openvswitch/ total 32 -rw-r-----. 1 openvswitch hugetlbfs 720 Jun 26 22:02 ovsdb-server.log -rw-r-----. 1 openvswitch hugetlbfs 27805 Jun 26 22:11 ovs-vswitchd.log [root@compute-0 heat-admin]# rpm -q openvswitch openvswitch-2.9.0-19.el7fdp.1.x86_64
The problem reported on comment #8 is on a fresh deploy of OSP10 with the async puddle. Minor update has the required changes (done before updating the ovs RPM). Either we need to take the new ovs package (2.9.0-47) or port the fix to 2.9.0-29-fdp.1 version. OSP13 fresh deploy also had the same problem, but fixed in the overcloud-full image preparation script, as stated here - https://bugzilla.redhat.com/show_bug.cgi?id=1589836#c39 The solution for this problem should be same on all releases. Can we use the same fix as OSP13 for now and update the ovs to the latest in the next release?
The code that we did was for minor update. In order to apply it, it required to execute minor update + reboot of the nodes (as the perm changes were done in a service, on start). We asked to do that permission changes on the ovs package directly, but for the update use case it was not possible because the package didn't want to be opinionated and force user permissions on update. On a fresh deploy, i think it makes sense that the ovs package sets the permissions correctly.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:2101