search

chr4-cookbooks / iptables-ng

Cookbook to maintain iptables rules and policies on different platforms, respecting the way the os handles these settings.
GNU General Public License v3.0
38 stars 32 forks source link

Remove unnecessary directory resource #46

Closed chewi closed 9 years ago

chewi commented 9 years ago

It's already covered by the preceding iptables_ng_chain resource. This will cut down some of the CHEF-3694 noise. The rest is harder to deal with in this cookbook but should be resolved anyway by chef/chef#2624.

chewi commented 9 years ago

Hmm, saying that, that Chef change was merged a while back now. I wonder why it's still complaining.

chewi commented 9 years ago

I should add that I tried to fix this another way by adding use_inline_resources. That didn't work and I understand why but it's going to become the default so that's something to watch out for. It sounds like non-inline mode is going to stick around but if it doesn't, I gather there's some hack you can do involving definitions?

chr4 commented 9 years ago

Maybe you're using a version of chef-client where the merge wasn't included yet? There was a way to find out since which release a merge was included, but I can't find it right now.

Regarding the patch: I think this is correctly spotted and should already be covered in the chain provider. Merging this, will test along with the other PR. Thanks!

chewi commented 9 years ago

Our Chef stuff is very up-to-date and Kitchen always grabs the latest so it's not that. I take it you see the noise too?

chr4 commented 9 years ago

I see tons of WARN: Cloning resource attributes for iptables-ng_chain[INPUT:filter:50-nginx] from prior resource (CHEF-3694) kind of warnings since forever. These are as far as I remember not fixable without hurting the cookbook massively, so I just discarded them.

I think this could very well be a problem on the Opscode side. Writing compatible, error-resiliant, intuitive cookbooks was always not really easy in Chef unfortunately.