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.
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
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.
Last night I was mistakenly using the image ID when trying to associate instead
of the server ID, so this fixes that. OpenStack wants a certain order of
operations for associating an IP as well, we must associate only after
OpenStack says the machine is ready.
This is the first half of the story, we need to make sure that the right
information is being persisted and then the second half can take place:
deassociating and releasing the floating IP
R. Tyler Croy
Chris Price
Branan Purvine-Riley