Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

no_security_group attr no longer available (was attrs not passed down to facet during construction) #140

agentgonzo opened this Issue Jun 15, 2012 · 2 comments


None yet
2 participants

When trying to create a facet without automatically creating a security group, the attrs object isn't passed down to the facet constructor from the cluster constructor.

Eg, in my cluster file, the following does NOT work:
facet :myfacet, {:no_security_group => true} do
instances 1

Here is the fix:
diff --git a/gems/1.9.1/gems/ironfan-3.1.5/lib/ironfan/cluster.rb b/gems/1.9.1/gems/ironfan-3.1.5/lib/ironfan/cluster.rb
index 7ceea2e..7eba600 100644
--- a/gems/1.9.1/gems/ironfan-3.1.5/lib/ironfan/cluster.rb
+++ b/gems/1.9.1/gems/ironfan-3.1.5/lib/ironfan/cluster.rb
@@ -50,7 +50,7 @@ module Ironfan
def facet(facet_name, attrs={}, &block)
facet_name = facet_name.to_sym

  •  @facets[facet_name] ||= Ironfan::Facet.new(self, facet_name)
  •  @facets[facet_name] ||= Ironfan::Facet.new(self, facet_name, attrs)
    @facets[facet_name].configure(attrs, &block)

temujin9 commented Sep 13, 2012

Thanks. Added that fix to v3.x.

I think the attribute resolution problem has been done correctly in the current version of Ironfan. However, I don't find the no_security_group flag in the new ensure_groups code. I'm updating this issue, since I intended to follow the v3 DSL as closely as possible, and this was an oversight.

I'm curious, however: what's the use-case for skipping the implied facet security group? I've found it easy enough to ignore the ones that don't actually matter, especially since the AWS console gives you per-instance visibility into what ports are opened by what group.

@temujin9 temujin9 closed this in 95c7c26 Sep 13, 2012

@temujin9 temujin9 reopened this Sep 13, 2012

The use-case is that we've currently got over 400 security groups and many of them are not used or needed. It's not a major thing and we can ignore them, but when we only use about 15 of them all that other clutter gets in the way - especially when we keep on creating test clusters under different names :-(

Thanks for the fixk.

@agentgonzo agentgonzo closed this Sep 14, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment