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.
R. Tyler Croy
Kohsuke Kawaguchi
Ryan Campbell
Jeff Blaine