i think its pulling from rubyforge? specify source more explicitly per gem in the repo.

If a non-standard port for sshd listening (or other ssh, scp options) on spawned nodes is used, the following construction, if supplied at the beginning of a clouds.rb file, is supposed to override the default port (or other ssh or scp -o settings):

module CloudProviders
module Connections

def ssh_options(opts={})
  o = {"-p" => '1999',
    "-i" => keypair.full_filepath,
    "-o" =>"StrictHostKeyChecking=no"
  }.merge(opts)
  o.collect{ |k,v| "#{k} #{v}"}.join(' ')
end
def scp_options(opts={})
  o = {"-P" => '1999',
    "-i" => keypair.full_filepath,
    "-o" =>"StrictHostKeyChecking=no"
  }.merge(opts)
  o.collect{ |k,v| "#{k} #{v}"}.join(' ')
end

end end

However, these module attributes are not used uniformly throughout PoolParty.

A verbose configure trace should list all the "def" steps performed by name (like "performing Foo.baz on host H" or "performing Foo.bar on prototype image for cloud Foop" or "performing Foo.fum on provisioner host).

The basic idea is that looking at verbose output should give amble clues as to what def section of which rb source file:

• is being performed

• is executing on what machine

• is probably emitting subsequent verbose logging messages

• is affecting which hosts

The would go a long way for troubleshooting and debugging.

There should be guarantees about state of clouds after a command returns (are all commands synchronous? Configuration seems to be, but cloud terminate is not; possibly have a command line flag to wait until done). This enables scripting.

I noticed this after I followed a "cloud terminate" quickly with a ec2-revoke and ec2-delete-group commands that failed because termination was not yet completed.

Running poolparty 1.3.16:

cloud-list provides listing- correctly.

Attempting to to run 'cloud-start' throws:
warning: peer certificate won't be verified in this SSL session
/var/lib/gems/1.8/gems/auser-poolparty-1.3.16/bin/../lib/keypair.rb:30:in expand_path': can't convert nil into String (TypeError) from /var/lib/gems/1.8/gems/auser-poolparty-1.3.16/bin/../lib/keypair.rb:30:infull_filepath'

    from /var/lib/gems/1.8/gems/auser-poolparty-1.3.16/bin/../lib/keypair.rb:19:in `exists?'                                  
    from /var/lib/gems/1.8/gems/auser-poolparty-1.3.16/bin/../lib/keypair.rb:90:in `keypair_found?'
    from /var/lib/gems/1.8/gems/auser-poolparty-1.3.16/bin/../lib/keypair.rb:73:in `send'
    from /var/lib/gems/1.8/gems/auser-poolparty-1.3.16/bin/../lib/keypair.rb:73:in `valid?

...and more which I can provide.

Thanks-

MK

Given:

using :ec2 do
  access_key 'something...'
  secret_access_key 'mysecret...'
  security_group do ...

security_group fails with :access_key_id not given. It's trying to instantiate a new instance of EC2 instead of using the instance from the using block. If it's going to make a new instance it should at least use the keys given to the containing block. This problem is easy to reproduce if you do not set ENV['EC2_ACCESS_KEY'] in your .profile or on the command line.

It seems more often than not when I start a cloud and its security group doesn't yet exist and will be created by poolparty, cloud-start will fail (supposedly after the security group has been created) when connections to port 22 get refused.

I'm able to relatively reliably reproduce the issue by starting from a virgin state: No instances, a custom security group expressed in my clouds.rb and no security groups created.

Currently, the paths in solo.rb are hardcoded to /etc/chef/chef-repo/site-cookbooks and /etc/chef/chef-repo/cookbooks. The problem is, when you call chef_repo in clouds.rb it simply copies the directory directly over so chef_repo "chef" would create /etc/chef/chef/* which doesn't match the expectations in the hardcoded solo.rb file.

For example, say you have chef_repo "chef" in your clouds.rb in a hypothetical "config" directory and run cloud-start from the parent directory giving the command line switch "-c config/clouds.rb". chef_repo will not find the "chef" directory so it will not copy your cookbooks.

The expectation is that it would find the directory relative to the clouds.rb file.