wr0ngway / rubber
- Source
- Commits
- Network (15)
- Issues (5)
- Downloads (14)
- Wiki (10)
- Graphs
-
Branch:
master
-
As can be seen in the following trace, rubber:describe_bundles seems to work fine, but when I try to delete a bundle using the AMI ID, things break.
~/d/w/gumshoe /master> cap rubber:describe_bundles triggering load callbacks * executing `rubber:init' * executing `rubber:describe_bundles' ** ID: ami-16dc3e7f ** Location: gumshoe_images_dev/ie6.manifest.xml ** ID: ami-98a84af1 ** Location: gumshoe_images_dev/staging-20091111_2057.manifest.xml ~/d/w/gumshoe /master> cap rubber:destroy_bundle triggering load callbacks * executing `rubber:init' * executing `rubber:destroy_bundle' The id of the image to be destroyed: ami-98a84af1 /Library/Ruby/Gems/1.8/gems/rubber-1.1.6/lib/rubber/cloud/aws.rb:258:in `destroy_image': Could not find image: ami-98a84af1, aborting destroy_image (RuntimeError) from /Library/Ruby/Gems/1.8/gems/rubber-1.1.6/lib/rubber/recipes/rubber/bundles.rb:16:in `load' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/configuration/execution.rb:139:in `instance_eval' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/configuration/execution.rb:139:in `invoke_task_directly_without_callbacks' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/configuration/callbacks.rb:27:in `invoke_task_directly' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/configuration/execution.rb:89:in `execute_task' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/configuration/execution.rb:101:in `find_and_execute_task' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/cli/execute.rb:45:in `execute_requested_actions_without_help' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/cli/execute.rb:44:in `each' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/cli/execute.rb:44:in `execute_requested_actions_without_help' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/cli/help.rb:19:in `execute_requested_actions' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/cli/execute.rb:33:in `execute!' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/lib/capistrano/cli/execute.rb:14:in `execute' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.10/bin/cap:4 from /usr/bin/cap:19:in `load' from /usr/bin/cap:19Comments
-
When using rubber with the most recent version of amazon-ec2 gem (0.7.5) there is an error due to :group_id being deprecated.
Have tested with the 0.5.x series and rubber works great. Nice work btw!
Cheers,
AlastairComments
Hi Alastair,
What rubber command were you running that failed? I've been using the 0.7.x gems without issues.
After testing a bit, 0.7.3 does work. 0.7.5 does not.
Thanks - seems like amazon-ec2 gem changed the params for run_instances - they replaced the group_id param with the security_group param. However, they also stopped allowing a list as its value, which is a requirement for rubber since EC2 doesn't allow one to change an instances security groups after creation. I'll check with the author.
I'll fix this as soon as its fixed upstream. In the meantime, use the older version of the gem. From grempe@github:
So according to the docs, the group_id param has been deprecated.
(Hmmm... now looking at the docs, they don't even say its deprecated, its just gone. I have seen lots of wierdness and changes like this in their docs before).
However, there is now a 'LaunchSpecification.SecurityGroup.n' option. Which at the time I updated to lib a couple of weeks ago was simply 'SecurityGroup'. (And not that since it was SecurityGroup and not SecurityGroup.n I implemented it as a simple string, not a list of strings. Sheesh.).
I'll update it today. You can let me know if its working as expected when I do.
FYI, I don't generally test all of this against the running API. I have to rely on the docs. There are just two many options and permutations to test and I just don't have time for that... So your report is just what is needed.
There's a new 0.7.7 version of the gem. rubber is still broken as is with that version, but perhaps his latest gem update would allow rubber to work as intended.
I had 0.7.7 before I messaged grempe - still waiting for him to release a fix
It might be a good idea to change the gemspec to reflect reality until then, so that it's at least possible to use 0.7.7 in other code without causing rubber to fall over.
-
(AWS::InvalidGroupNotFound) when adding rules to appname_env_default security group
5 comments Created 2 months ago by bcasci- Security Group already in cloud, syncing rules: loudcaster_production_mysql_master
- Security Group already in cloud, syncing rules: loudcaster_production_web
- Security Group already in cloud, syncing rules: loudcaster_production_haproxy
- Security Group already in cloud, syncing rules: loudcaster_production_apache
- Security Group already in cloud, syncing rules: loudcaster_production_app
- Security Group already in cloud, syncing rules: loudcaster_production_passenger
- Security Group already in cloud, syncing rules: loudcaster_production_db
- Security Group already in cloud, syncing rules: loudcaster_production_web_tools
- Security Group already in cloud, syncing rules: loudcaster_production_beta
- Security Group already in cloud, syncing rules: loudcaster_production_default
- Missing rule, creating: {"source_group_account"=>"aws@loudcaster.net", "source_group_name"=>"loudcaster_production_default"}
/usr/lib/ruby/gems/1.8/gems/amazon-ec2-0.5.5/lib/AWS.rb:282:in
aws_error?': The security group 'loudcaster_production_default' does not exist (AWS::InvalidGroupNotFound) from /usr/lib/ruby/gems/1.8/gems/amazon-ec2-0.5.5/lib/AWS.rb:220:inmake_request' from /usr/lib/ruby/1.8/net/http.rb:543:instart' from /usr/lib/ruby/gems/1.8/gems/amazon-ec2-0.5.5/lib/AWS.rb:194:inmake_request' from /usr/lib/ruby/gems/1.8/gems/amazon-ec2-0.5.5/lib/AWS.rb:245:inresponse_generator' from /usr/lib/ruby/gems/1.8/gems/amazon-ec2-0.5.5/lib/AWS/EC2/security_groups.rb:122:inauthorize_security_group_ingress' from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/cloud/aws.rb:117:inadd_security_group_rule' from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/recipes/rubber/security_groups.rb:154:insync_security_groups' from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/recipes/rubber/security_groups.rb:149:ineach' from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/recipes/rubber/security_groups.rb:149:insync_security_groups' from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/recipes/rubber/security_groups.rb:103:ineach' from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/recipes/rubber/security_groups.rb:103:insync_security_groups' from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/recipes/rubber/security_groups.rb:51:insetup_security_groups' from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/recipes/rubber/instances.rb:158:increate_instance' from /usr/lib/ruby/gems/1.8/gems/rubber-1.1.4/lib/rubber/recipes/rubber/instances.rb:36:inload' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/configuration/execution.rb:128:ininstance_eval' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/configuration/execution.rb:128:ininvoke_task_directly_without_callbacks' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/configuration/callbacks.rb:27:ininvoke_task_directly' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/configuration/execution.rb:81:inexecute_task' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/configuration/execution.rb:93:infind_and_execute_task' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/cli/execute.rb:45:inexecute_requested_actions_without_help' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/cli/execute.rb:44:ineach' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/cli/execute.rb:44:inexecute_requested_actions_without_help' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/cli/help.rb:19:inexecute_requested_actions' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/cli/execute.rb:33:inexecute!' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/capistrano/cli/execute.rb:14:inexecute' from /usr/lib/ruby/gems/1.8/gems/capistrano-2.5.5/bin/cap:4 from /usr/bin/cap:19:in `load' from /usr/bin/cap:19 brandon@dell-desktop:~/projects/rails_apps/loudcaster_new$
Comments
The security group in question is created and does exist.
setting isolate_security_groups in rubber.yml to false bypassed this problem.
Just for fun I created a new EC2 account and had rubber create an instance on there, just to take away the question if there was conflict with something in the other account. No dice. isolate_security_groups: false has to be set.
From the trace, it looks like your AWS account has an incorrect value, the AWS account should be a numeric ID, not an email address: "source_group_account"=>"aws@loudcaster.net"
Is "cloud_providers -> aws -> account" set to a numeric ID in your rubber.yml?
You can find your AWS account ID by logging into the portal at aws.amazon.com -remove the dashes before adding it into rubber.ymlLet me know if that works.
Damn it.....I'm sorry. I totally missed that detail. I'm so used to plopping in the account name. It's purring along with the security group stuff now.
-
Rubber runs rake install:gems at the wrong time
1 comment Created 3 months ago by wr0ngwayWhen setting up a staging instance, during the first deploy rubber
tries to run "rake gems:install" before a rubber:config has
transformed and placed all templates, including the database.yml. This
makes gems:install fail.Does this happen to anyone else? Or is it maybe a problem with our
environment configuration inside the Rails app?
Comments
-
I tried the rubber and it created the ec2 instances. But failed when it was about to change/setup the dns aliases. I was trying with the zerigo. The following is the error:
* executing `rubber:setup_aliases' * executing `rubber:setup_local_aliases' ** Writing out aliases into local machines /etc/hosts, sudo access needed [sudo] password for millisami: * executing `rubber:setup_remote_aliases' ** No servers for task setup_remote_aliases, skipping * executing `rubber:setup_dns_aliases' ./vendor/plugins/rubber/lib/rubber/dns/zerigo.rb:53:in `refresh': undefined method `find' for nil:NilClass (NoMethodError) from ./vendor/plugins/rubber/lib/rubber/dns/zerigo.rb:16:in `initialize' from ./vendor/plugins/rubber/lib/rubber/dns/zerigo.rb:81:in `new' from ./vendor/plugins/rubber/lib/rubber/dns/zerigo.rb:81:in `initialize' from ./vendor/plugins/rubber/lib/rubber/dns.rb:9:in `new' from ./vendor/plugins/rubber/lib/rubber/dns.rb:9:in `get_provider' from ./vendor/plugins/rubber/lib/rubber/recipes/rubber/setup.rb:228:in `destroy_dyndns' from ./vendor/plugins/rubber/lib/rubber/recipes/rubber/instances.rb:311:in `destroy_instance' from ./vendor/plugins/rubber/lib/rubber/recipes/rubber/instances.rb:59:in `load' ... 15 levels... from /opt/ruby-enterprise-1.8.6-20090610/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/cli/execute.rb:14:in `execute' from /opt/ruby-enterprise-1.8.6-20090610/lib/ruby/gems/1.8/gems/capistrano-2.5.8/bin/cap:4 from /opt/ruby_ee/bin/cap:19:in `load' from /opt/ruby_ee/bin/cap:19Comments
Looks like a bad error message if authentication is wrong, check your zerigo settings (customerId, token and email) in rubber.yml - note you need to setup a token in zerigo's web ui before this will work.
Also found another problem while investigating this that caused a NoMemoryError
Both fixed in 1.0.2
-
Bad error message if invalid nettica credentials provided
1 comment Created 3 months ago by nirvdrumI had the wrong nettica credentials in my rubber.yml file, causing DNS updates to fail. Rubber incorrectly reported the issue as being related to the DNS not existing in nettica. This should be updated to reflect the true error.
/Library/Ruby/Gems/1.8/gems/wr0ngway-rubber-1.0.1/lib/rubber/dns/nettica.rb:21:in `host_exists?': Domain needs to exist in nettica before records can be updated (RuntimeError)
Comments
-
Rubber doesn't handle multiple versions of amazon-ec2 gem
3 comments Created 4 months ago by nirvdrum$ gem list | grep amazon-ec2 amazon-ec2 (0.5.0, 0.4.5)
$ RAILS_ENV=nirvdrum cap rubber:create_staging triggering load callbacks * executing `rubber:init' /Users/nirvdrum/Gentoo/usr/lib/ruby/site_ruby/1.8/rubygems.rb:280:in `activate': can't activate amazon-ec2 (= 0.4.5, runtime) for [], already activated amazon-ec2-0.5.0 for ["rubber-0.9.4"] (Gem::LoadError) from /Users/nirvdrum/Gentoo/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:35:in `require' from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/rubber-0.9.4/lib/rubber/cloud/aws.rb:2 from /Users/nirvdrum/Gentoo/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /Users/nirvdrum/Gentoo/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require' from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/rubber-0.9.4/lib/rubber/cloud.rb:7:in `get_provider' from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/rubber-0.9.4/lib/rubber/recipes/rubber.rb:51:in `load' from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/configuration/execution.rb:139:in `instance_eval' from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/configuration/execution.rb:139:in `invoke_task_directly_without_callbacks' from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/configuration/callbacks.rb:27:in `invoke_task_directly' from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/configuration/execution.rb:89:in `execute_task' from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/configuration/execution.rb:101:in `find_and_execute_task' from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/callback.rb:38:in `call' from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/configuration/callbacks.rb:128:in `trigger' from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/configuration/callbacks.rb:128:in `each' from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/configuration/callbacks.rb:128:in `trigger' from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/cli/execute.rb:32:in `execute!' from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/lib/capistrano/cli/execute.rb:14:in `execute' from /Users/nirvdrum/Gentoo/usr/lib/ruby/gems/1.8/gems/capistrano-2.5.8/bin/cap:4 from /Users/nirvdrum/Gentoo/usr/bin/cap:19:in `load' from /Users/nirvdrum/Gentoo/usr/bin/cap:19Comments
I couldn't duplicate this, but then I also made some fixes around how rubber uses AWS::EC2. Can you try with the latest on cleanup branch?






Fix is in master.