On Thu, May 26, 2016 at 4:16 PM, Ben Nemec <[email protected]> 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
