Bug 1572219

Summary: Incorrect ownership of /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/blah
Product: Red Hat OpenStack Reporter: coldford <coldford>
Component: openstack-tripleoAssignee: Raildo Mascena de Sousa Filho <rmascena>
Status: CLOSED DUPLICATE QA Contact: Arik Chernetsky <achernet>
Severity: high Docs Contact:
Priority: high    
Version: 12.0 (Pike)CC: dvd, hrybacki, jjoyce, jschluet, marjones, mburns, pkesavar, rhos-maint, rmascena, slinaber, tvignaud
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-05-16 19:26:08 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 coldford@redhat.com 2018-04-26 12:34:11 UTC 
Description of problem:

After updating the keystone_domain_specific_ldap_backend.yaml template, a deployment results in incorrect ownership(root:root) of the generated files in /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains. The end user manually had to chown 42425:42425 in order to achieve functionality.

Version-Release number of selected component (if applicable):
OSP12

How reproducible:
Always with LDAP authentication

Steps to Reproduce:
1. Configure LDAP authentication
2. Deploy or update 

Actual results:
/var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/blah owned by root:root


Expected results:
/var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/blah owned by 42425:42425

Additional info:
Comment 1 David Vallee Delisle 2018-04-27 13:27:30 UTC 
We got confirmation that after a restart of the container, the file is not owned by 42425 instead of root. Can we integrate the container restart in the update process?
Comment 8 Harry Rybacki 2018-05-16 19:26:08 UTC 

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