…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
Fix instance_data lookups to use symbols
…ed we'll choose the first ship we find
…nstack blimps 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.
…ing boxes from .blimp files
…mpy.d state files
… to tear down their floating ip
… and associate an IP 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