Prior to this commit, when SecurityGroups#ensure_group was called with a list of ports that there was not yet a security group for, the array of ports would get wrapped in `Set.new` twice; once in the body of #group_id and once in the body of #ensure_group. It turns out that, based on the implementation of #group_id, there are cases when you'd get back a different group_id when you converted the array to a set twice. So, e.g.: Zlib.crc32(Set.new([22,8140]).inspect) != Zlib.crc32(Set.new(Set.new([22,8140])).inspect) but... Zlib.crc32(Set.new([22,8080]).inspect) == Zlib.crc32(Set.new(Set.new([22,8080])).inspect) Good times. This commit tweaks the tests so that they would repro this issue, and also cleans up the handling of the calls to `Set.new` so as to fix the bug.
…_file API Fixes #53
…osts for invoking the Puppet binary provided by the gem
…lready in our PATH
This will allow for easier bootstrapping and configuration of Puppet on a machine, e.g.: Blimpy.fleet do |f| f.add(:aws) do |s| s.livery = Blimpy::Livery::Puppet.configure |c| c.module_path = "test/modules" # This is relative to the Blimpfile's root directory end end end In a way, this should fix #47
… scenario work
…re "structure" This effectively breaks the crap out of existing Blimpfiles with a `ship.livery = :cwd` line, or something similar. I think it's worth it at this point. Liveries will have some access to the box object itself, so that API will need to remain consistent for some time. It's expected that every Livery will have at least: * setup_on(box) * preflight(box) * flight(box) * postflight(box) This should be enough for just about every livery to do what it needs to do with the created box. This should also allow (in the future) a Livery to express variables or other configuration information "outward" for the consumption of other Liveries.
… abstraction Fixes #49
…ed we'll choose the first ship we find