I recently started running into an issue with the 'knife ec2 server list’
that I suspect is caused by knife having an issue handling responses from
Amazon.
I’m using the Opscode platform free account.
With Ruby 1.8.7 and Chef 0.9.14 on OS X I get this output:
4:20PM <kelp@kelp-mac:~/chef-repo 1 %> knife ec2 server list
DEBUG: Using configuration from /Users/kelp/chef-repo/.chef/knife.rb
[WARN] Fog::AWS::Compute.new is deprecated, use
Fog::Compute.new(:provider => ‘AWS’) instead
(/Users/kelp/.rvm/gems/ruby-1.8.7-p334/gems/fog-0.7.2/lib/fog/core/service.rb:58:in
new') [WARN] Fog::AWS::Compute::Server => #ip_address is deprecated, use #public_ip_address instead (/Users/kelp/.rvm/gems/ruby-1.8.7-p334/gems/fog-0.7.2/lib/fog/compute/models/aws/server.rb:9) [WARN] Fog::AWS::Compute::Server => #ip_address is deprecated, use #public_ip_address instead (/Users/kelp/.rvm/gems/ruby-1.8.7-p334/gems/fog-0.7.2/lib/fog/compute/models/aws/server.rb:9) [WARN] Fog::AWS::Compute::Server => #ip_address is deprecated, use #public_ip_address instead (/Users/kelp/.rvm/gems/ruby-1.8.7-p334/gems/fog-0.7.2/lib/fog/compute/models/aws/server.rb:9) [WARN] Fog::AWS::Compute::Server => #ip_address is deprecated, use #public_ip_address instead (/Users/kelp/.rvm/gems/ruby-1.8.7-p334/gems/fog-0.7.2/lib/fog/compute/models/aws/server.rb:9) [WARN] Fog::AWS::Compute::Server => #ip_address is deprecated, use #public_ip_address instead (/Users/kelp/.rvm/gems/ruby-1.8.7-p334/gems/fog-0.7.2/lib/fog/compute/models/aws/server.rb:9) /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:330:inscan_line’: private method scan' called for {}:Hash (NoMethodError) from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:318:incall’
from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:318:in
percent_line' from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:308:inscan’
from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:307:in each' from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:307:inscan’
from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:500:in
compile' from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:668:ininitialize’
from /Users/kelp/.rvm/gems/ruby-1.8.7-p334/gems/highline-1.6.1/lib/highline.rb:376:in
new' from /Users/kelp/.rvm/gems/ruby-1.8.7-p334/gems/highline-1.6.1/lib/highline.rb:376:inlist’
from /Users/kelp/.rvm/gems/ruby-1.8.7-p334/gems/highline-1.6.1/lib/highline.rb:375:in
map' from /Users/kelp/.rvm/gems/ruby-1.8.7-p334/gems/highline-1.6.1/lib/highline.rb:375:inlist’
from /Users/kelp/.rvm/gems/ruby-1.8.7-p334/gems/chef-0.9.14/lib/chef/knife/ec2_server_list.rb:82:in
run' from /Users/kelp/.rvm/gems/ruby-1.8.7-p334/gems/chef-0.9.14/lib/chef/knife.rb:127:inrun’
from /Users/kelp/.rvm/gems/ruby-1.8.7-p334/gems/chef-0.9.14/lib/chef/application/knife.rb:121:in
run' from /Users/kelp/.rvm/gems/ruby-1.8.7-p334/gems/chef-0.9.14/bin/knife:25 from /Users/kelp/.rvm/gems/ruby-1.8.7-p334/bin/knife:19:inload’
from /Users/kelp/.rvm/gems/ruby-1.8.7-p334/bin/knife:19
If I switch to chef 0.10.0.beta.7 and knife-ec2 0.5.4 I basically get the
same result:
4:28PM <kelp@kelp-mac:~/chef-repo 1 %> knife ec2 server list
ERROR: knife encountered an unexpected error
This may be a bug in the ‘ec2 server list’ knife command or plugin
Exception: NoMethodError: private method `scan’ called for {}:Hash
Same thing on Ruby 1.9.2p180 on OS X or Ubuntu 10.04.
Interestingly this problem only shows up in my QA ec2 account. It works fine
in my production ec2 account, which makes me think it’s something knife
doesn’t like in my QA account. I was testing VPC there, but hadn’t got knife
to work with it yet.
knife ec2 server create works fine.
Any idea what’s going on here? Or something I could look at to track it
down?
-kelp
Zoosk Ops
On Thu, Apr 7, 2011 at 4:41 PM, Travis Cole kelp@zoosk.com wrote:
I recently started running into an issue with the 'knife ec2 server list'
that I suspect is caused by knife having an issue handling responses from
Amazon.
Any idea what's going on here? Or something I could look at to track it
down?
In situations such as this, I automatically blame gems getting
installed that aren't backwards compatible.
Output of 'gem list'?
Bryan
5:10PM <kelp@kelp-mac:~/chef-repo 1 %> gem list
*** LOCAL GEMS ***
builder (3.0.0)
bunny (0.6.0)
chef (0.10.0.beta.7)
erubis (2.7.0)
excon (0.6.1)
extlib (0.9.15)
fog (0.7.2)
formatador (0.1.3)
highline (1.6.1)
json (1.4.6)
knife-ec2 (0.5.4)
mime-types (1.16)
mixlib-authentication (1.1.4)
mixlib-cli (1.2.0)
mixlib-config (1.1.2)
mixlib-log (1.3.0)
moneta (0.6.0)
net-ssh (2.1.4)
net-ssh-gateway (1.0.1)
net-ssh-multi (1.0.1)
nokogiri (1.4.4)
ohai (0.5.8)
polyglot (0.3.1)
rake (0.8.7)
rest-client (1.6.1)
ruby-hmac (0.4.0)
systemu (1.2.0)
treetop (1.4.9)
uuidtools (2.1.2)
-kelp
Zoosk Ops
On Thu, Apr 7, 2011 at 4:45 PM, Bryan McLellan btm@loftninjas.org wrote:
On Thu, Apr 7, 2011 at 4:41 PM, Travis Cole kelp@zoosk.com wrote:
I recently started running into an issue with the 'knife ec2 server list'
that I suspect is caused by knife having an issue handling responses from
Amazon.
Any idea what's going on here? Or something I could look at to track it
down?
In situations such as this, I automatically blame gems getting
installed that aren't backwards compatible.
Output of 'gem list'?
Bryan
On Thu, Apr 7, 2011 at 5:11 PM, Travis Cole kelp@zoosk.com wrote:
5:10PM <kelp@kelp-mac:~/chef-repo 1 %> gem list
Nothing stands out in the list of gems.
I wonder if it is trying to draw bad data. What about editing
/Users/kelp/.rvm/gems/ruby-1.8.7-p334/gems/chef-0.9.14/lib/chef/knife/ec2_server_list.rb
around line 73 and commenting out some of the columns of data that are
being passed there (and decrementing the column integer on line 82)?
Bryan
Hmm, yeah that's interesting.
If I comment this out:
server_list << server.state
Then it works.
-kelp
Zoosk Ops
On Thu, Apr 7, 2011 at 5:42 PM, Bryan McLellan btm@loftninjas.org wrote:
On Thu, Apr 7, 2011 at 5:11 PM, Travis Cole kelp@zoosk.com wrote:
5:10PM <kelp@kelp-mac:~/chef-repo 1 %> gem list
Nothing stands out in the list of gems.
I wonder if it is trying to draw bad data. What about editing
/Users/kelp/.rvm/gems/ruby-1.8.7-p334/gems/chef-0.9.14/lib/chef/knife/ec2_server_list.rb
around line 73 and commenting out some of the columns of data that are
being passed there (and decrementing the column integer on line 82)?
Bryan
On Thu, Apr 7, 2011 at 5:55 PM, Travis Cole kelp@zoosk.com wrote:
Hmm, yeah that's interesting.
If I comment this out:
server_list << server.state
See what is up with that data:
Chef::Log.info("Server state: #{pp server.state}")
Bryan
6:04PM <kelp@kelp-mac:~/chef-repo 0 %> knife ec2 server list
DEBUG: Using configuration from /Users/kelp/chef-repo/.chef/knife.rb
[WARN] Fog::AWS::Compute.new is deprecated, use Fog::Compute.new(:provider
=> 'AWS') instead
(/Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/gems/fog-0.6.0/lib/fog/core/service.rb:58:in
new') [WARN] Fog::AWS::Compute::Server => #ip_address is deprecated, use #public_ip_address instead (/Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14 /gems/fog-0.6.0/lib/fog/compute/models/aws/server.rb:9) [WARN] Fog::AWS::Compute::Server => #ip_address is deprecated, use #public_ip_address instead (/Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14 /gems/fog-0.6.0/lib/fog/compute/models/aws/server.rb:9) "running" INFO: Server state: [WARN] Fog::AWS::Compute::Server => #ip_address is deprecated, use #public_ip_address instead (/Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14 /gems/fog-0.6.0/lib/fog/compute/models/aws/server.rb:9) "running" INFO: Server state: [WARN] Fog::AWS::Compute::Server => #ip_address is deprecated, use #public_ip_address instead (/Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14 /gems/fog-0.6.0/lib/fog/compute/models/aws/server.rb:9) [WARN] Fog::AWS::Compute::Server => #ip_address is deprecated, use #public_ip_address instead (/Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14 /gems/fog-0.6.0/lib/fog/compute/models/aws/server.rb:9) [{}] INFO: Server state: /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:330:in scan_line': private method scan' called for {}:Hash (NoMethodError) from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:318:in call'
from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:318:in
percent_line' from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:308:in scan'
from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:307:in
each' from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:307:in scan'
from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:500:in
compile' from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:668:in initialize'
from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/gems/highline-1.6.1/lib/highline.rb:376:in
new' from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/gems/highline-1.6.1/lib/highline.rb:376:in list'
from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/gems/highline-1.6.1/lib/highline.rb:375:in
map' from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/gems/highline-1.6.1/lib/highline.rb:375:in list'
from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/gems/chef-0.9.14/lib/chef/knife/ec2_server_list.rb:83:in
run' from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/gems/chef-0.9.14/lib/chef/knife.rb:127:in run'
from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/gems/chef-0.9.14/lib/chef/application/knife.rb:121:in
run' from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14 /gems/chef-0.9.14/bin/knife:25 from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/bin/knife:19:in load'
from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/bin/knife:19
If I change the server.state line to:
server_list << server.state.to_s
Then it works. One of my instances seems to be returning an empty state.
-kelp
Zoosk Ops
On Thu, Apr 7, 2011 at 6:02 PM, Bryan McLellan btm@loftninjas.org wrote:
On Thu, Apr 7, 2011 at 5:55 PM, Travis Cole kelp@zoosk.com wrote:
Hmm, yeah that's interesting.
If I comment this out:
server_list << server.state
See what is up with that data:
Chef::Log.info("Server state: #{pp server.state}")
Bryan
Though oddly ec2-describe-instances shows it as running, as does the AWS
Management Console.
-kelp
Zoosk Ops
On Thu, Apr 7, 2011 at 6:06 PM, Travis Cole kelp@zoosk.com wrote:
6:04PM <kelp@kelp-mac:~/chef-repo 0 %> knife ec2 server list
DEBUG: Using configuration from /Users/kelp/chef-repo/.chef/knife.rb
[WARN] Fog::AWS::Compute.new is deprecated, use
Fog::Compute.new(:provider => 'AWS') instead
(/Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/gems/fog-0.6.0/lib/fog/core/service.rb:58:in
new') [WARN] Fog::AWS::Compute::Server => #ip_address is deprecated, use #public_ip_address instead (/Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14 /gems/fog-0.6.0/lib/fog/compute/models/aws/server.rb:9) [WARN] Fog::AWS::Compute::Server => #ip_address is deprecated, use #public_ip_address instead (/Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14 /gems/fog-0.6.0/lib/fog/compute/models/aws/server.rb:9) "running" INFO: Server state: [WARN] Fog::AWS::Compute::Server => #ip_address is deprecated, use #public_ip_address instead (/Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14 /gems/fog-0.6.0/lib/fog/compute/models/aws/server.rb:9) "running" INFO: Server state: [WARN] Fog::AWS::Compute::Server => #ip_address is deprecated, use #public_ip_address instead (/Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14 /gems/fog-0.6.0/lib/fog/compute/models/aws/server.rb:9) [WARN] Fog::AWS::Compute::Server => #ip_address is deprecated, use #public_ip_address instead (/Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14 /gems/fog-0.6.0/lib/fog/compute/models/aws/server.rb:9) [{}] INFO: Server state: /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:330:in scan_line': private method scan' called for {}:Hash (NoMethodError) from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:318:in call'
from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:318:in
percent_line' from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:308:in scan'
from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:307:in
each' from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:307:in scan'
from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:500:in
compile' from /Users/kelp/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/erb.rb:668:in initialize'
from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/gems/highline-1.6.1/lib/highline.rb:376:in
new' from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/gems/highline-1.6.1/lib/highline.rb:376:in list'
from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/gems/highline-1.6.1/lib/highline.rb:375:in
map' from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/gems/highline-1.6.1/lib/highline.rb:375:in list'
from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/gems/chef-0.9.14/lib/chef/knife/ec2_server_list.rb:83:in
run' from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/gems/chef-0.9.14/lib/chef/knife.rb:127:in run'
from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/gems/chef-0.9.14/lib/chef/application/knife.rb:121:in
run' from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14 /gems/chef-0.9.14/bin/knife:25 from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/bin/knife:19:in load'
from /Users/kelp/.rvm/gems/ruby-1.8.7-p334@chef-0.9.14/bin/knife:19
If I change the server.state line to:
server_list << server.state.to_s
Then it works. One of my instances seems to be returning an empty state.
-kelp
Zoosk Ops
On Thu, Apr 7, 2011 at 6:02 PM, Bryan McLellan btm@loftninjas.org wrote:
On Thu, Apr 7, 2011 at 5:55 PM, Travis Cole kelp@zoosk.com wrote:
Hmm, yeah that's interesting.
If I comment this out:
server_list << server.state
See what is up with that data:
Chef::Log.info("Server state: #{pp server.state}")
Bryan
On Thu, Apr 7, 2011 at 6:09 PM, Travis Cole kelp@zoosk.com wrote:
Though oddly ec2-describe-instances shows it as running, as does the AWS
Management Console.
Yeah, so we can probably change that to:
server_list << (server.state == nil ? "" : server.state)
like the others. It'd be interesting to follow that back in the code
and see if you can find out if Fog is giving us the empty state or if
we've got a bug somewhere that is losing it.
Bryan