Bug 1301050

I originally assigned this to Ryan Hallisey, but mburns tells me we need to either add restorecon to the image build process or move openstack-selinux install earlier.

The original bug was opened against OSP 8.  Has this actually been reproduced on OSP 7?  I'm not seeing it on images built against the latest 7.3 poodle:

[root@overcloud-compute-0 etc]# ls -lZ machine-id 
-r--r--r--. root root unconfined_u:object_r:machineid_t:s0 machine-id

And systemd-journald is running fine:

[root@overcloud-compute-0 heat-admin]# systemctl status systemd-journald
● systemd-journald.service - Journal Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static; vendor preset: disabled)
   Active: active (running) since Fri 2016-01-22 18:18:00 EST; 8min ago

The deployment completed fine and a quick sanity check shows the major services working fine.  I guess it's possible something is broken only in the Brew builds, but if that's the case then I need to know which specific images have the problem.

Ofer, can you comment please?

Hi Ben,

We encountered this bug on an earlier 7.3 puddle during IPv6 tests: https://bugzilla.redhat.com/show_bug.cgi?id=1300800 which was verified.

Okay, so the bug (https://bugzilla.redhat.com/show_bug.cgi?id=1300800) was verified as fixed.  That indicates to me that this problem did not block them from deploying anymore.  Are there any ongoing instances of this bug?  I haven't been able to reproduce it, so I would have no way to verify whether any changes fix the problem.  Without a reproducer I don't know what we can do about this.

We manged to solve it due to https://bugzilla.redhat.com/show_bug.cgi?id=1293942
workaround.

I think the disk image builder added a restorecon so we will not encounter this.

Mike, can you confirm/reject?

diskimage-builder has always done a restorecon at the end of the build.  Based on the fact that Rhys is seeing this in a packstack install I'm 99% sure this isn't an image problem.  I suspect something in the puppet modules we use to install both was causing the issue.  Beyond that speculation I can't say much more though.  In any case, if this is not reproducible in the latest images I'm inclined to say it should not be a blocker.  If somebody is able to reproduce it then we can look further.

Since the other bug is verified, marking this as a duplicate.  If this reproduces, please reopen.

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

I agree. I'll keep my eyes open for this one.

(In reply to Ben Nemec from comment #5)
> Okay, so the bug (https://bugzilla.redhat.com/show_bug.cgi?id=1300800) was
> verified as fixed.  That indicates to me that this problem did not block
> them from deploying anymore.  Are there any ongoing instances of this bug? 
> I haven't been able to reproduce it, so I would have no way to verify
> whether any changes fix the problem.  Without a reproducer I don't know what
> we can do about this.

Hi Ben, just for completeness, I've just deployed a Mitaka environment generating images from scratch and the problem is still there:

[root@overcloud-controller-1 ~]# ls -lZ /etc/machine-id 
-rw-r--r--. root root system_u:object_r:unlabeled_t:s0 /etc/machine-id

So without the workaround I mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1293942.