Security Groups as first-class Citizens of Clusters and Realms, and other cloud issues

[howech]

Ironfan curreently represents security groups as being tied eplicitly to the ec2 cloud dsl object (and in a recent patch, i the openstack cloud provider).

It would be nice if instead, security groups were their own entity in the realm or cluster, etc. Often, in cluster files, I see things like

   facet :something do
     instances 1
     cloud(:ec2).flavor 'c1.large'
     cloud(:ec2).security_group(:something_server).authorize(:something_client)
  end

Now, in general, if I have the choice of deploying this thing on ec2, openstack, or something else, I am going to want this security group to be build by the cloud provider however it happens to do it. The flavor is another matter - I could easily want different flavors based on the provider, so it might make sense to talk about multiple clouds as a kind of conditional configuration:

   facet :something do
     instances 1
     cloud(:ec2).flavor 'c1.large'
     cloud(:openstack).flavor 'x1.custom'
     security_group(:something_server).authorize(:something_client)
  end

The idea here is that if you happen to launch this facet into ec2, it will show up as a c1 large, but if you launch it into openstack, it will show up as an 'x1.custom' (that hopefully you have set up already on you openstack cluster.) In either case, an appropriate security group will be provisioned that allows :sopmething clients to attach to servers, and adds the given instance into the security group.

To keep backwards compatibility, I would allow the cloud(:ec2).security_group behavior to work - only in would be interpreted as "If you deploy into ec2, set up this security group thusly".

[joshbronson]

+1 from me. I'd vote for deprecating the old functionality, though, since the logic around the DSL and in

https://github.com/infochimps-labs/ironfan/blob/master/lib/ironfan/provider/ec2/security_group.rb

is already pretty complicated.

[mrflip]

Yes that should move to facet.

If you are preserving cloud(:ec2).security_group, choose another word for this when on the facet: ie new syntax would be facet(:bob){ network_group(:roberts) }. Only preserve security group as new way if the old way will break loudly.

Both this and really everything on cloud need a rethink though, I'll follow up with thoughts.

On Jan 16, 2014, at 1:38 PM, joshbronson notifications@github.com wrote:

+1 from me. I'd vote for deprecating the old functionality, though, since the logic around the DSL and in

https://github.com/infochimps-labs/ironfan/blob/master/lib/ironfan/provider/ec2/security_group.rb

is already pretty complicated.

—
Reply to this email directly or view it on GitHub.

[howech]

I don't really see the conflict between having cloud(:whatever).security_groups and facet(:whatever).security_groups. In reality, I am not putting the security_groups container on facet - I am putting it on the Compute class, so that you can talk about security groups for a cluster, a facet, or a specific server.