…_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
…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.