Previously, the PackStack all-in-one installation process would fail under certain conditions when more than one Swift disk was specified. This was caused by the logic used to deploy firewall rules during the swift.pp puppet run, whereby the rules would be deployed for each device rather than for each host, resulting in duplicate entries. Now, the logic used to deploy firewall rules has been revised so that those rules are only deployed once for each host, making it possible to specify more than one Swift disk.
DescriptionMartina Kollarova
2014-03-03 20:33:45 UTC
Created attachment 870125[details]
packstack answerfile
Description of problem:
I get the following error if I have more than one disk in the storage host list:
ERROR : Error appeared during Puppet run: 192.168.1.15_swift.pp
Error: Definition 'add_allow_host' is already defined at /var/tmp/packstack/28cf0412278c4d34a5e6e1792c057eb1/manifests/192.168.1.15_swift.pp:99; cannot be redefined at /var/tmp/packstack/28cf0412278c4d34a5e6e1792c057eb1/manifests/192.168.1.15_swift.pp:122 on node mkollaro-destroystack-singlenode.novalocal
For example:
CONFIG_SWIFT_STORAGE_HOSTS=192.168.1.38/vdb1,192.168.1.38/vdb2,192.168.1.38/vdb3
The problem goes away when I specify only one disk, for example:
CONFIG_SWIFT_STORAGE_HOSTS=192.168.1.38/vdb1
But then I happened upon another bug (will be reported in a moment).
Maybe somewhat related to bug #1048705, where there is a similar problem with add_allow_host. Is it possible that somebody introduced these issues in one patch? If so, the whole patch should be reviewed anew.
Version-Release number of selected component (if applicable):
rhel6.5
puddle 2014-02-28.3
openstack-packstack-2013.2.1-0.25.dev987.el6ost.noarch
openstack-swift-1.10.0-3.el6ost.noarch
How reproducible:
100%
Steps to Reproduce:
1. use more than one disk in the swift storage hosts options
2.
3.
Actual results:
Expected results:
Additional info:
Comment 2Martina Kollarova
2014-03-03 22:28:09 UTC
The bug I mentioned is this - #1072099 (Cannot specify Swift disk, only loopback device).
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.
http://rhn.redhat.com/errata/RHEA-2014-0846.html