Description of problem: Version-Release number of selected component (if applicable): openstack-packstack.noarch 2015.2-0.1.dev1654.gcbbf46e.el7 @openstack-liberty How reproducible: 1ßß% Steps to Reproduce: sudo yum update -y sudo yum install -y https://www.rdoproject.org/repos/rdo-release.rpm sudo yum install -y openstack-packstack packstack --allinone Actual results: ERROR : Error appeared during Puppet run: 192.168.121.187_prescript.pp Error: Evaluation Error: Error while evaluating a Function Call, Could not find data item CONFIG_USE_SUBNETS in any Hiera data file and no default supplied at /var/tmp/packstack/7c0f1f44cd854c0c965dd30fe2659094/manifests/192.168.121.187_prescript.pp:2:22 on node controller.localhost Expected results: A working openstack
Created attachment 1098249 [details] Full output Also reproduced with --provision-demo=y
Thanks for reporting this. After some tests, it looks like this issue is caused by a newer version of hiera available in EPEL (3.0.1 vs 1.3.4 that was commonly used with Packstack). The hiera.yaml provided by this new version includes the following hierachy: :hierarchy: - "nodes/%{::trusted.certname}" - common That means hiera will look for a file called common.yaml, as opposed to defaults.yaml that was used with 1.3.4. Since hiera cannot find the file, the first reference to a variable fails. As a workaround until the proper fix is merged, we can blacklist the EPEL hiera package by adding the following to /etc/yum.repos.d/epel.repo: [epel] ... gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 exclude=hiera*
Commit https://review.openstack.org/249300 with a fix is now merged. Also backported to Kilo (https://review.openstack.org/249301) and Juno (https://review.openstack.org/249303).
BTW EPEL is not required (and not tested in CI jobs) with RDO >= Kilo
Confirmed that the version in delorean fixes this bug. Note that yum-plugin-priorities was required because the openstack-packstack package is both in delorean and delorean-deps. The semver from delorean-deps was older but was considered more up-to-date due to a higher semver ? Haikel explained this as: For RPM, release "0.4.dev1661.gaf13b7e.el7" (in liberty testing) > "dev1673.gdc3e416.el7" (in delorean) hence RPM thinking the one in liberty testing is newer than the one in delorean.
CI is green on current, running a full batch of tests before promoting to current-passed-ci.
@Alan Pevec: If you execute the "Summary for impatient" on the RDO page (https://www.rdoproject.org/install/quickstart/), EPEL gets pulled in on CentOS 7 (tested with vagrant centos/7 box). Idk exactly at what step and currently I don't got the time to test that out, but if your CI jobs don't test EPEL, you should definitely not have RDO do that by default.
Quickstart instructuons do not enable EPEL repo explicitly, I'll have a look at where EPEL gets enabled. What was exactly your base vagrant centos/7 image? Re. comment 5 - delorean repo requires yum priorities instead of relying on upstream generated Version-Release. Fix could be to make Delorean and/or PBR generate Fedora compliant pre-release NVR but that's fragile. I'll rebuild packstack RPM for RDO Juno/Kilo/Liberty repos to include patches from comment 3.
Packstack enables EPEL automatically when a package called rdo-release is installed. This was needed before (maybe < or <= Kilo?) and it has never been removed since. Since EPEL is not a requirement anymore (even for RHEL?), we can remove that code now.
(In reply to Javier Peña from comment #9) > Packstack enables EPEL automatically when a package called rdo-release is > installed. This was needed before (maybe < or <= Kilo?) and it has never > been removed since. That should be removed for >= Kilo but OTOH users could have EPEL enabled for other reasons, so we need to make it work with EPEL either enable or disabled.
openstack-packstack-7.0.0-0.5.dev1661.gaf13b7e.el7 is now in RDO Liberty testing repo buildlogs.centos.org/centos/7/cloud/x86_64/openstack-liberty/
openstack-packstack-2015.1-0.13.dev1616.g5526c38.el7 is now in RDO Kilo testing repo http://buildlogs.centos.org/centos/7/cloud/x86_64/openstack-kilo/
Follow up fix: * Wed Nov 25 2015 Javier Peña <jpena> - 2015.1-0.14.dev.dev1616.g5526c38 - Do not enable EPEL when installing RDO
I confirm the error and but the workaround to exclude=hiera* from epel doesn't worked well for me. I had to install these testing package right before running packstack: for kilo: sudo yum install -y \ http://buildlogs.centos.org/centos/7/cloud/x86_64/openstack-kilo/openstack-packstack-2015.1-0.13.dev1616.g5526c38.el7.noarch.rpm \ http://buildlogs.centos.org/centos/7/cloud/x86_64/openstack-kilo/openstack-packstack-puppet-2015.1-0.13.dev1616.g5526c38.el7.noarch.rpm for liberty: sudo yum install -y \ http://buildlogs.centos.org/centos/7/cloud/x86_64/openstack-liberty/openstack-packstack-7.0.0-0.7.dev1661.gaf13b7e.el7.noarch.rpm \ http://buildlogs.centos.org/centos/7/cloud/x86_64/openstack-liberty/openstack-packstack-puppet-7.0.0-0.7.dev1661.gaf13b7e.el7.noarch.rpm Thanks!
I have tested openstack-packstack-7.0.0-0.7 from the liberty-testing repo, and I can confirm it works fine in an allinone install.
(In reply to Tristan Cacqueray from comment #14) > I confirm the error and but the workaround to exclude=hiera* from epel > doesn't worked well for me. [...] It does work, but has to be done on all nodes not just the one you execute packstack from.
Published in RDO Liberty http://mirror.centos.org/centos/7/cloud/x86_64/openstack-liberty/openstack-packstack-7.0.0-0.7.dev1661.gaf13b7e.el7.noarch.rpm
Alvaro, it used to failed on allinone single node when epel was already installed and hiera was downgraded to hiera-1.3.4-1.el7.noarch (CentOS 7). It's like the exclude was not enough to prevent this bug. Anyways, I can't reproduce this anymore since the fixing packages is now in the main repository. All good now, thanks!