Allows control over when the livery provisioning happens for
ships. This was needed because sometimes we don't want to
provision (Puppet) until all ships are up and we know their
hostnames in AWS, etc.
(04:25:26 PM) rtyler: kohsuke: so `blimpy ssh` is going to return immediately now?
(04:25:41 PM) kohsuke: yes, it fails if ssh fails
(04:26:09 PM) ***rtyler is a bit confused
(04:26:14 PM) rtyler: this seems like a big UX change then
(04:26:21 PM) ***rtyler should read more carefully
(04:27:13 PM) kohsuke: Yes, modifying a test case made me wonder if there's a better way to do it
(04:28:00 PM) kohsuke: (though in practice you wouldn't see any change as "blimpy provision" does wait for ssh to come online)
(04:28:13 PM) rtyler: but a `blimpy ssh` won't log me into the machine?
(04:28:51 PM) kohsuke: I think just reporting ">> Connecting: SHIPNAME..." if the first attempt fails would be sufficient
(04:29:25 PM) kohsuke: The "gotcha" that made me write that patch is that my first attempt to use blimpy failed miserably at "blimpy ssh"
(04:29:51 PM) kohsuke: because it was trying a wrong user name, and I couldn't Ctrl+C it because of another bug that since then I fixed
(04:30:11 PM) rtyler: with aws and openstack it connects multiple times, usually the machine isn't accepting ssh connections right away
(04:30:14 PM) rtyler: especially on a fresh image
(04:30:25 PM) kohsuke: yes, I understand why you wrote it the way you did the first place
(04:31:17 PM) rtyler: heh
(04:31:21 PM) rtyler: alright
(04:32:05 PM) kohsuke: Let me change it to ">> Connecting: user@SHIPNAME:port" with dots added over time,
(04:32:15 PM) kohsuke: and if it's killed by SIGINT I'll run ssh one last time but without -q
(04:32:22 PM) kohsuke: so you see the error message
(04:32:41 PM) kohsuke: does that sound OK to you?
(04:34:30 PM) rtyler: that does sound good
It turns out some mode of failure includes ssh hanging (such as trying a
wrong port), so silently re-running SSH again wasn't very wise. Instead,
show the command line needed to let the user run the ssh command by
himself.
in 1.9, the original code was sufficient, but 1.10 has a massive
refactoring in the way of registering providers. Unless at least one
provider is registered, the providers hash is empty, and it causes
an exception like the following:
/var/lib/gems/1.8/gems/fog-1.10.0/lib/fog/compute.rb:39:in `new': undefined method `include?' for nil:NilClass (NoMethodError)
from /home/kohsuke/ws/cloudbees/blimpy/lib/blimpy/boxes/aws.rb:39:in `fog'
from /home/kohsuke/ws/cloudbees/blimpy/lib/blimpy/boxes/aws.rb:32:in `validate!'
from /home/kohsuke/ws/cloudbees/blimpy/lib/blimpy/fleet.rb:110:in `start'
from /home/kohsuke/ws/cloudbees/blimpy/lib/blimpy/fleet.rb:109:in `each'
from /home/kohsuke/ws/cloudbees/blimpy/lib/blimpy/fleet.rb:109:in `start'
from /home/kohsuke/ws/cloudbees/blimpy/lib/blimpy/cli.rb:73:in `start'
from /var/lib/gems/1.8/gems/thor-0.18.0/lib/thor/command.rb:27:in `__send__'
from /var/lib/gems/1.8/gems/thor-0.18.0/lib/thor/command.rb:27:in `run'
from /var/lib/gems/1.8/gems/thor-0.18.0/lib/thor/invocation.rb:120:in `invoke_command'
from /var/lib/gems/1.8/gems/thor-0.18.0/lib/thor.rb:363:in `dispatch'
from /var/lib/gems/1.8/gems/thor-0.18.0/lib/thor/base.rb:427:in `start'
from /home/kohsuke/ws/cloudbees/blimpy/bin/blimpy:24
By forcing the registration of a provider, it works against with fog
1.10. Looking at the source tree, this change should also work with fog
1.9.
1. If your Blimpfile is misconfigured, you'll not get any diagnostics information.
2. When you press Ctrl+C, blimpy doesn't exit because it's just ssh getting killed (and blimp ignores that)
There appears to be no provision for handling options, so I just made it a separate command
This will fail trying to chmod the entire puppet command string
chmod: unrecognized option '--modulepath=./modules'
Try `chmod --help' for more information.
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.
Kohsuke Kawaguchi
Ryan Campbell
R. Tyler Croy
Jeff Blaine
Chris Price
Branan Purvine-Riley