This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1000851 - Openstack does not persist after a system reboot
Openstack does not persist after a system reboot
Status: CLOSED DUPLICATE of bug 981583
Product: RDO
Classification: Community
Component: distribution (Show other bugs)
unspecified
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: RHOS Maint
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-25 20:12 EDT by marcus young
Modified: 2015-01-07 18:35 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-15 10:17:46 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description marcus young 2013-08-25 20:12:55 EDT
Description of problem:
After rebooting the system immediately after a fresh allinone install, no services are available

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


How reproducible:
Always

Steps to Reproduce:
1. Fresh install fedora 19 
2. sudo yum install openstack-packstack
3. Restart

Actual results:
Nothing responds on http://server/dashboard

Expected results:
Openstack UI responds

Additional info:
Comment 1 marcus young 2013-08-25 20:18:49 EDT
(In reply to marcus young from comment #0)
> Description of problem:
> After rebooting the system immediately after a fresh allinone install, no
> services are available
> 
> Version-Release number of selected component (if applicable):
> 
> 
> How reproducible:
> Always
> 
> Steps to Reproduce:
> 1. Fresh install fedora 19 
> 2. sudo yum install openstack-packstack
> 3. Restart
> 
> Actual results:
> Nothing responds on http://server/dashboard
> 
> Expected results:
> Openstack UI responds
> 
> Additional info:

Sorry, step 3 is 'sudo packstack --allinone', step 4 is 'Restart'
Comment 2 marcus young 2013-08-25 22:30:46 EDT
More details. Made permanent Permissive selinux and it worked. On reboot, still was not able to browse. It's iptables. Although it had changes before reboot to allow access, they did not stick. Changed /etc/sysconfig/iptables to the lines below, and am persistently able to browse and use openstack after reboot.


/etc/sysconfig/iptables:

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -p icmp -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -i eth0 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
Comment 3 Jiri Stransky 2013-09-09 10:32:27 EDT
Yeah this is also the case if you install RDO using Foreman, as it uses packstack's puppet modules.

I think the reason is that we use outdated fork of `firewall` module in packstack. Maybe we could fix this by using the upstream module from puppetlabs.

https://github.com/stackforge/packstack/tree/bb7e9dd8af4d994048d3fcb76a1601a6ec16073a/packstack/puppet/modules
Comment 4 Jiri Stransky 2013-09-09 10:57:54 EDT
We're using some 0.0.4 fork of puppetlabs-firewall, and they seem to have some automatic persistent rules support since 0.2.0 or so. (Current upstream version is 0.4.1.)
Comment 5 Lars Kellogg-Stedman 2014-01-15 10:17:46 EST
Thanks for the report.  This happens because our current puppet modules do not support firewalld.  https://bugzilla.redhat.com/show_bug.cgi?id=981583 is already open on this issue.

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

Note You need to log in before you can comment on or make changes to this bug.