Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Model cleanup, knife cluster bootstrap fix, integration specs. #179

Merged
merged 7 commits into from Oct 1, 2012

Conversation

Projects
None yet
2 participants
Owner

mrflip commented Sep 30, 2012

  • Specs for scripts (but not really) -- Tried to see if I could do specs for scripts without a mock mode for chef. It works-ish but I'd like to see if this is really the right approach.
    • ironfan_go! spec helper loads the basic chef environment. Chef will as usual look for a .chef directory holding a knife.rb, etc -- if there's one in the repo root, it will be used.
    • added a demo cluster, and a serialized version of its computers
    • Fixed an error in Ironfan.load_cluster when using a string vs. a symbol to load
  • Model cleanup -- So that I can load fixtures, made it so that models will accept the serialized versions of themselves. This involved overriding a couple receive_foo methods, fixing some types (eg provider takes a Class, not an Ironfan::Provider), and making sure that hash keys are symbolized.
  • knife cluster bootstrap sets Chef::Config[:environment](fixes #148) -- I can't see a way (or a need) for bootstrapping under multiple simultaneous environments. The bootstrap script runs one single command across all its machines; anything else would involve lots of code. The command will fail if you ask for an inconsistent script to be run, but now works correctly.

Philip (flip) Kromer added some commits Sep 30, 2012

Rescue on duplicate security groups; don't die logging on full 'load!'
* launching multiple machines with a common security group would cause all but one to lose the race; this is especially exciting if they manage to tangle up the reload.
  Am now rescuing the error, and inserting a short sleep() to get some extra splay into the works.
* Dialed up the default splay in Ironfan.parallel to 0.25
* was not checking whether the cluster was nil in 'load!', causing it to die logging. Fixed my error.
Terminated machines are not bogus
The dead are not bogus (Bill & Ted I), they're ghosts (Bill & Ted II)

* terminated machines are skipped, as they were in old ironfan.
* ...except in the case of knife cluster show, which accepts them as there-but-bogus if verbosity > 1.
Changed key_pair to keypair, as per the DSL
The DSL has always used 'keypair' not 'key_pair'. The only touchpoints to key_pair were internal.

With a facade in place, there's no reason to go with Fog's opinion over our own DSL's. This patch makes ironfan use 'keypair' uniformly.
Specs for scripts (but not really)
Tried to see if I could do specs for scripts without a mock mode for chef. It works but I'd like to see if this is really the right approach.

* ironfan_go! spec helper loads the basic chef environment. Chef will as usual look for a .chef directory holding a knife.rb, etc -- if there's one in the repo root, it will be used.
* added a demo cluster, and a serialized version of its computers
* Fixed an error in Ironfan.load_cluster when using a string vs. a symbol to load
Model cleanup -- now mostly round-trip to JSON
Made it so that models will accept the serialized versions of themselves. This involved overriding a couple receive_foo methods, fixing some types (eg provider takes a Class, not an Ironfan::Provider), and making sure that hash keys are symbolized.
knife cluster bootstrap sets Chef::Config[:environment] (fixes #148)
I did a little dip into the bootstrap code; in order to make bootstrap work if there are multiple environments in the slice, you'll have to identify the subgroups with each environment and coordinate launching an ssh session on each.
knife bootstrap prepares a single template file that draws on the Chef::Config[:environment] setting, and uses that as the command to a knife::Ssh session. at that point it's in Net::Ssh's hands. Anything we did that was non-uniform would lose parallel ssh sessions.

Instead, knife checks the slice and, as long as all the machines you're bootstrapping live in the same environment, sets the Chef::Config and carries on. If you have multiple environments it explains and raises an exception.

So you can still have a cluster with multiple environments, you just have to bootstrap them in groups by environment.

@temujin9 temujin9 merged commit 7d65273 into master Oct 1, 2012

Contributor

temujin9 commented Oct 1, 2012

The specs on these are awfully noisy, especially given that they're passing. Can you quiet them down a little?

WARN: Failed to read the private key /etc/chef/client.pem: #<Errno::ENOENT: No such file or directory - /etc/chef/client.pem>
WARNING: Error running Ironfan::Provider::ChefServer::Client[adaptee,bogus,key_filename]:
WARNING: I cannot read /etc/chef/client.pem, which you told me to use to sign requests!
ERROR: I cannot read /etc/chef/client.pem, which you told me to use to sign requests! (Chef::Exceptions::PrivateKeyMissing)
/usr/share/ruby-rvm/gems/ruby-1.9.2-p180/gems/chef-10.12.0/lib/chef/rest/auth_credentials.rb:63:in `rescue in load_signing_key'
/usr/share/ruby-rvm/gems/ruby-1.9.2-p180/gems/chef-10.12.0/lib/chef/rest/auth_credentials.rb:59:in `load_signing_key'
/usr/share/ruby-rvm/gems/ruby-1.9.2-p180/gems/chef-10.12.0/lib/chef/rest/auth_credentials.rb:34:in `initialize'
/usr/share/ruby-rvm/gems/ruby-1.9.2-p180/gems/chef-10.12.0/lib/chef/rest.rb:61:in `new'
/usr/share/ruby-rvm/gems/ruby-1.9.2-p180/gems/chef-10.12.0/lib/chef/rest.rb:61:in `initialize'
/usr/share/ruby-rvm/gems/ruby-1.9.2-p180/gems/chef-10.12.0/lib/chef/search/query.rb:34:in `new'
/usr/share/ruby-rvm/gems/ruby-1.9.2-p180/gems/chef-10.12.0/lib/chef/search/query.rb:34:in `initialize'
/home/temujin9/Projects/InfoChimps/code/ironfan-knife/lib/ironfan/provider/chef.rb:24:in `new'
/home/temujin9/Projects/InfoChimps/code/ironfan-knife/lib/ironfan/provider/chef.rb:24:in `search'
/home/temujin9/Projects/InfoChimps/code/ironfan-knife/lib/ironfan/provider/chef/client.rb:49:in `load!'
/home/temujin9/Projects/InfoChimps/code/ironfan-knife/lib/ironfan/provider.rb:35:in `block in load'
/home/temujin9/Projects/InfoChimps/code/ironfan-knife/lib/ironfan.rb:35:in `block (3 levels) in parallel'
/home/temujin9/Projects/InfoChimps/code/ironfan-knife/lib/ironfan.rb:134:in `safely'
/home/temujin9/Projects/InfoChimps/code/ironfan-knife/lib/ironfan.rb:34:in `block (2 levels) in parallel'
ERROR: /usr/share/ruby-rvm/gems/ruby-1.9.2-p180/gems/chef-10.12.0/lib/chef/rest/auth_credentials.rb:63:in `rescue in load_signing_key'
/usr/share/ruby-rvm/gems/ruby-1.9.2-p180/gems/chef-10.12.0/lib/chef/rest/auth_credentials.rb:59:in `load_signing_key'
/usr/share/ruby-rvm/gems/ruby-1.9.2-p180/gems/chef-10.12.0/lib/chef/rest/auth_credentials.rb:34:in `initialize'
/usr/share/ruby-rvm/gems/ruby-1.9.2-p180/gems/chef-10.12.0/lib/chef/rest.rb:61:in `new'
/usr/share/ruby-rvm/gems/ruby-1.9.2-p180/gems/chef-10.12.0/lib/chef/rest.rb:61:in `initialize'
/usr/share/ruby-rvm/gems/ruby-1.9.2-p180/gems/chef-10.12.0/lib/chef/search/query.rb:34:in `new'
/usr/share/ruby-rvm/gems/ruby-1.9.2-p180/gems/chef-10.12.0/lib/chef/search/query.rb:34:in `initialize'
/home/temujin9/Projects/InfoChimps/code/ironfan-knife/lib/ironfan/provider/chef.rb:24:in `new'
/home/temujin9/Projects/InfoChimps/code/ironfan-knife/lib/ironfan/provider/chef.rb:24:in `search'
/home/temujin9/Projects/InfoChimps/code/ironfan-knife/lib/ironfan/provider/chef/client.rb:49:in `load!'
/home/temujin9/Projects/InfoChimps/code/ironfan-knife/lib/ironfan/provider.rb:35:in `block in load'
/home/temujin9/Projects/InfoChimps/code/ironfan-knife/lib/ironfan.rb:35:in `block (3 levels) in parallel'
/home/temujin9/Projects/InfoChimps/code/ironfan-knife/lib/ironfan.rb:134:in `safely'
/home/temujin9/Projects/InfoChimps/code/ironfan-knife/lib/ironfan.rb:34:in `block (2 levels) in parallel'
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment