Open Stack

On Thu, May 26, 2016 at 4:16 PM, Ben Nemec <openstack at nemebean.com> wrote:
> Pretty much what the subject says.  I've recently gotten several
> questions from the field about why their deployments had no firewall
> enabled, and discovered that although we have support built-in to enable
> the firewall, we turn it off by default.  This seems like a bad default
> to me, but I wanted to send something out in case there was a good
> historical reason we chose to do this.
>
> I'm also wondering about the upgrade implications of changing defaults
> in Heat templates.  If we did this, would it cause the firewall to be
> enabled on existing deployments when they upgraded to the new version?
> That seems like a significant concern since it's quite possible users
> are managing their own firewall rules (especially because we don't by
> default), and they may have customizations that they won't want us
> stepping on.
>
> I've pushed a review to flip the bit on this:
> https://review.openstack.org/#/c/321833 but I've set it WIP until we
> have answers to the topics above.
>
> -Ben

When Yanis and I wrote the feature back in times, we wanted the
feature experimental because it's very intrusive.
Now our CI is a good shape and has good coverage, I think we can give
a try to enable it.
If you enable, just make sure tripleo::firewall::post::debug is set at
False, otherwise traffic won't be dropped :-)

I don't see any issue on the upgrade thing, we just to iptables commands.

I like your idea and I'm in favor of enabling it by default, and
iterate on errors that we might encounter in CI.

Thanks!
-- 
Emilien Macchi