Description of problem: Undercloud installation failed. puppet apply exited with exit code 1 Version-Release number of selected component (if applicable): instack-0.0.8-1.el7ost.noarch instack-undercloud-2.2.0-1.el7ost.noarch How reproducible: 100 % Steps to Reproduce: 1.install virt 'instack-virt-setup' 2.install tripleO client 'sudo yum install -y python-tripleoclient' 3.disable the selinux. sudo setenforce Permissive 4.install openstack: openstack --debug --log-file=undercloud_install.log undercloud install Actual results: undercloud installation failed echo 'puppet apply exited with exit code 1' Expected results: Additional info: log of undercloud installation: http://file.tlv.redhat.com/~rrasouli/install-undercloud.log
can we have your version of openstack-puppet-modules please? Thanks!
Created attachment 1114400 [details] Keystone_domain patch This patch fix it. If you want to add manually the fix, the file is located at /usr/share/instack-undercloud/puppet-stack-config/puppet-stack-config.pp
openstack-puppet-modules-7.0.3-1.el7ost.noarch
Testing the fix in comment 3 works Adding the to undercloud/puppet-stack-config/puppet-stack-config.pp keystone_domain { 'heat_domain': ensure => present }
One more thing: This code that is using Keystone_domain is from github.com/rdo-management/instack-undercloud and the latest commit there is from September 2015. According Ana Krivokapic, they move to upstream in github.com/openstack/instack-undercloud. I'm not sure what's the deal here, keep using old content for OSPD 8 or have a new package pointing to the new repository upstream.
Resource Keystone_domain['heat_domain'] makes the error go away, but won't actually fix the issue. The problem is that Keystone_domain['heat_domain'] resource seems missing in class ::heat::keystone::domain. The cause of this error is actually line: Service['keystone'] -> Class['::keystone::roles::admin'] -> Keystone_domain['heat_domain'] Since in the class there's used ensure_resource for resource creation [1], there's IMHO possibility that Puppet does not have Heat_domain resource in the catalog at the time the line above is being parser. Hence better fix would be to change that to: Service['keystone'] -> Class['::keystone::roles::admin'] -> Class['::heat::keystone::domain'] [1] https://github.com/openstack/puppet-heat/blob/master/manifests/keystone/domain.pp#L79
Just noticed that default value in the class is "$domain_name = 'heat'", so even following should help, but fix afrom comment #8 seems more flexible for me: Service['keystone'] -> Class['::keystone::roles::admin'] -> Keystone_domain['heat']
FWIW I did encounter this problem in instack-undercloud 2.2.0 (puddle) but not in instack-undercloud 2.2.1 (poodle)
*** Bug 1299625 has been marked as a duplicate of this bug. ***
I can confirm that the following change in line 299 of file /usr/share/instack-undercloud/puppet-stack-config/puppet-stack-config.pp will fix the problem we have seen during "openstack undercloud install" with OSP 8 Beta 4 from the partner ftp site: old: Service['keystone'] -> Class['::keystone::roles::admin'] -> Keystone_domain['heat_domain'] new: Service['keystone'] -> Class['::keystone::roles::admin'] -> Class['::heat::keystone::domain'] Regards, Ralf (Fujitsu)
Still happening on beta 5 ( workaround mentioned in #12 works)
Hi, I hit the same bug with the last OSP-d 8 puddle but the provided patch fixes the issue. Regards,
*** Bug 1306855 has been marked as a duplicate of this bug. ***
verified on instack-undercloud-2.2.2-1.el7ost.noarch The keystone changed to domain see below: # to make sure they are done in order. include ::keystone::roles::admin Service['keystone'] -> Class['::keystone::roles::admin'] -> Class['::heat::keystone::domain']
Beta6 - still an issue.
Hi, works for me with OSP 8 Beta 7. Thanks! Regards, Ralf
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://rhn.redhat.com/errata/RHEA-2016-0604.html
*** Bug 1306002 has been marked as a duplicate of this bug. ***