Latest != Greatest

While setting up a private cloud with packstack, it turned out I came too late to the show one more time. Or … too early for the issues ironed out by others.

Setting up my first proper cloud, I wanted to follow the nice Building an Openstack Cloud blog post. And it worked, at least until some odd error struck: running »packstack ‐‐answer-file=multi-node.txt« constantly failed in my environment with:

ERROR : Error appeared during Puppet run: 10.99.2.10_neutron.pp
Error: The ovs_redhat provider can not handle attribute external_ids

There exists a bugzilla entry for this bug on a version near mine (dev840, I had dev876), but there’s not much attention to it :(

Anyway, time to understand that the latest version is a dead end for the intented setup — let’s downgrade:

Running Transaction
  Installing : openstack-packstack-2013.2.1-0.11.dev806.el6.noarch              
  Cleanup    : openstack-packstack-2013.2.1-0.17.dev876.el6.noarch              
  Verifying  : openstack-packstack-2013.2.1-0.11.dev806.el6.noarch              
  Verifying  : openstack-packstack-2013.2.1-0.17.dev876.el6.noarch              

Removed:
  openstack-packstack.noarch 0:2013.2.1-0.17.dev876.el6                         

Installed:
  openstack-packstack.noarch 0:2013.2.1-0.11.dev806.el6                         

Complete!

Yeah. That was the easy part. Now neutron gets installed, but the journey is not over yet:

ERROR : Error appeared during Puppet run: 10.99.2.3_swift.pp
Error: Parameter source failed on Firewall[001 swift storage and rsync incoming 10.99.2.3/mapper/Swift]: Munging failed for value "10.99.2.3/mapper/Swift" in class source: no address for 10.99.2.3/mapper/Swift at /var/tmp/packstack/a6e0306b07504a04ba581cb7bdba039f/manifests/10.99.2.3_swift.pp:41
You will find full trace in log /var/tmp/packstack/20131214-192811-7d4mdY/manifests/10.99.2.3_swift.pp.log

This is a nice one, actually — it’s fixed in a commit on Github, easily appliable locally.

Next one was maybe related to CentOS 6.4; »nrpe« was replaced by »nagios-nrpe«. Time to tell puppet:

--- /usr/lib/python2.6/site-packages/packstack/puppet/templates/nagios_nrpe.pp.orig     2013-08-01 13:24:14.000000000 +0200
+++ /usr/lib/python2.6/site-packages/packstack/puppet/templates/nagios_nrpe.pp 2013-12-14 23:49:19.000000000 +0100
@@ -1,4 +1,4 @@
-package{'nrpe':
+package{'nagios-nrpe':
     ensure => present,
     before => Class['nagios_configs']
 }

Well, this lets the Nagios stuff pass. But now there’s another issue, as this packstack version seems to be unable to create an SSL certificate for Horizon — and trying to back out of https triggers another bug:

Error: The iptables provider can not handle attribute dport
Error: /Firewall[001 horizon incoming]/dport: change from 443 to 80 failed: The iptables provider can not handle attribute dport

This seems to be an issue with puppet, but it is supposed to be fixed since puppet 3.0.0 — while I’m at 3.3.2. A recent bug against RDO at least tells me I am not alone … Whatever; »iptables -F« before re-running »packstack« solves it for now.

Finalizing...                                          [ DONE ]

 **** Installation completed successfully ******

Have to state, though, that it took a bit longer than 15 minutes to get going.