I'm running Rubber 3.2.2 and am trying to get an instance provisioned in my staging environment. As a part of this, I was wanting to put it into a different security group (staging_default). I've tried a couple of different things, but it continually puts it into the 'default' security group.
Here's the relevant portion of my rubber.yml (I thought that I could override assigned_security_groups for the specific environment):
security_groups:
default:
description: The default security group
rules:
- source_group_name: default
source_group_account: "#{cloud_providers.aws.account}"
- protocol: tcp
from_port: 22
to_port: 22
staging_default:
description: The default staging security group
rules:
- source_group_name: staging_default
source_group_account: "#{cloud_providers.aws.account}"
- protocol: tcp
from_port: 22
to_port: 22
# OPTIONAL: The default security groups to create instances with
assigned_security_groups: [default]
# OPTIONAL: Automatically create security groups for each host and role
# EC2 Classic doesn't allow one to change what groups an instance belongs to after
# creation, so it's good to have some empty ones predefined. EC2 with VPC, however,
# does allow changing security groups after instance creation and allows far fewer
# security groups per instance, so you shouldn't enable this setting if using VPC.
auto_security_groups: false
# OPTIONAL: Automatically isolate security groups for each appname/environment
# by mangling their names to be appname_env_groupname
# This makes it safer to have staging and production coexist on the same EC2
# account, or even multiple apps. NB: due to the security group limits per instance
# in EC2 with VPCs, this option should only be enabled if you're using EC2 Classic.
isolate_security_groups: false
# OPTIONAL: Prompts one to sync security group rules when the ones in amazon
# differ from those in rubber
prompt_for_security_group_sync: true
# OPTIONAL: A list of CIDR address blocks that represent private networks for your cluster.
# Set this to open up wide access to hosts in your network. Consequently, setting the CIDR block
# to anything other than a private, unroutable block would be a massive security hole.
# OPTIONAL: The packages to install on all instances
# You can install a specific version of a package by using a sub-array of pkg, version
# For example, packages: [[rake, 0.7.1], irb]
packages: [postfix, build-essential, git-core, libxslt-dev, ntp]
# OPTIONAL: The command used to identify your particular OS version. This will be used for configurations
# in Rubber templates that are parameterized by OS version (e.g., package lists). If not specified, Ubuntu
# will be assumed.
os_version_cmd: 'lsb_release -sr'
# OPTIONAL: gem sources to setup for rubygems
# OPTIONAL: The gems to install on all instances
# You can install a specific version of a gem by using a sub-array of gem, version
# For example, gem: [[rails, 2.2.2], open4, aws-s3]
gems: [open4, aws-s3, bundler, [rubber, "#{Rubber.version}"]]
# OPTIONAL: A string prepended to shell command strings that cause multi
# statement shell commands to fail fast. You may need to comment this out
# on some platforms, but it works for me on linux/osx with a bash shell
#
stop_on_error_cmd: "function error_exit { exit 99; }; trap error_exit ERR"
# OPTIONAL: The default set of roles to use when creating a staging instance
# with "cap rubber:create_staging". By default this uses all the known roles,
# excluding slave roles, but this is not always desired for staging, so you can
# specify a different set here
#
# staging_roles: "web,app,db:primary=true"
# Auto detect staging roles
staging_roles: "web,app,db:primary=true,memcached,sidekiq,redis_master,postgresql,postgresql_master"
roles:
app:
packages: [imagemagick]
environments:
staging:
assigned_security_groups: [staging_default]
Any help would be greatly appreciated.