Bug 1941052

Summary: 16.1z3 to 16.1z4 minor update on Director node causing some Selinux issues.
Product: Red Hat OpenStack Reporter: Shravan Kumar Tiwari <shtiwari>
Component: openstack-swift-plugin-swift3Assignee: Pete Zaitcev <zaitcev>
Status: CLOSED DUPLICATE QA Contact: Mike Abrams <mabrams>
Severity: high Docs Contact:
Priority: high    
Version: 16.1 (Train)CC: derekh, jelle.hoylaerts.ext, lmarsh, zaitcev
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-03-24 15:34:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Shravan Kumar Tiwari 2021-03-19 20:20:55 UTC
A minor update from OSP16.1 z3 -> z4 started and and started on director node.

The "openstack undercloud upgrade" ran fine.

But further commands like  "openstack overcloud image upload --update-existing --image-path /home/stack/images/" and "openstack overcloud node configure $(openstack baremetal node list -c UUID -f value)" are  not working anymore.


Logs from glance/swift it seems like some permissions are missing.



Additional Information:

When did some comparison between an cloud that is in z3 and z4, a difference in selinux contexts on this path observed as shown below:

On a working z3:
===================
 [root@dir001 stack]# ls -lZ /srv/
total 0
drwxr-xr-x. 3 42445 42445 system_u:object_r:container_file_t:s0 16 Jan 15 12:40 node
 [root@dir001 stack]# ls -lZ /srv/node/
total 0
drwxr-xr-x. 7 42445 42445 system_u:object_r:container_file_t:s0 87 Jan  4 15:53 d1
 [root@dir001 stack]# ls -lZ /srv/node/d1/
total 72
drwxr-xr-x.    5 42445 42445 system_u:object_r:container_file_t:s0    39 Jan  4 14:48 accounts
drwxr-xr-x.    2 42445 42445 system_u:object_r:container_file_t:s0     6 Mar 19 09:21 async_pending
drwxr-xr-x.  925 42445 42445 system_u:object_r:container_file_t:s0 16384 Mar 19 09:10 containers
drwxr-xr-x. 1026 42445 42445 system_u:object_r:container_file_t:s0 20480 Feb  5 12:51 objects
drwxr-xr-x.    2 42445 42445 system_u:object_r:container_file_t:s0     6 Mar 19 09:19 tmp

On a broken z4:
======================
[root@dir001 stack]# ls -lZ /srv/
total 0
drwxr-xr-x. 3 42445 42445 system_u:object_r:container_file_t:s0 16 Mar  2 13:46 node
[root@dir001 stack]# ls -lZ /srv/node/
total 0
drwxr-xr-x. 7 42445 42445 system_u:object_r:swift_data_t:s0 87 Mar  2 15:21 d1
[root@dir001 stack]# ls -lZ /srv/node/d1/
total 56
drwxr-xr-x.    5 42445 42445 system_u:object_r:swift_data_t:s0    39 Mar  2 14:06 accounts
drwxr-xr-x.    2 42445 42445 system_u:object_r:swift_data_t:s0     6 Mar 19 11:25 async_pending
drwxr-xr-x.  469 42445 42445 system_u:object_r:swift_data_t:s0  8192 Mar 19 11:23 containers
drwxr-xr-x. 1026 42445 42445 system_u:object_r:swift_data_t:s0 20480 Mar 18 16:20 objects
drwxr-xr-x.    2 42445 42445 system_u:object_r:swift_data_t:s0     6 Mar 19 11:24 tmp


Tried changing selinux to permissive:
=======================================

Just for a test customer placed selinux to permissive mode to have a look if it solves the issue and it does.
So it looks like the upgrade process has broken some of the selinux permissions.

Comment 2 Pete Zaitcev 2021-03-23 14:17:36 UTC
This appears to be a duplicate of bug 1941412, see comment
https://bugzilla.redhat.com/show_bug.cgi?id=1941412#c3

Comment 3 Laura Marsh 2021-03-24 15:34:12 UTC

*** This bug has been marked as a duplicate of bug 1941412 ***