Jira (PDB-1263) Round robin support for EC2 subnets

2 views
Skip to first unread message

Ryan Senior (JIRA)

unread,
Feb 25, 2015, 10:03:45 AM2/25/15
to puppe...@googlegroups.com
Ryan Senior created an issue
 
PuppetDB / New Feature PDB-1263
Round robin support for EC2 subnets
Issue Type: New Feature New Feature
Assignee: Unassigned
Created: 2015/02/25 7:02 AM
Priority: Normal Normal
Reporter: Ryan Senior

Using VPCs requires that we pin our instances to a specific subnet which also implies a specific availability zone. Under normal conditions this is fine, but when one availability zone is at capacity, it results in errors like the one below:

[AWS EC2 500 0.194905 0 retries] run_instances(:block_device_mappings=>[{:device_name=>"/dev/sda1",:ebs=>{:delete_on_termination=>true,:volume_size=>8}}],:client_token=>"35a3e6d2-119b-431b-94c1-7bcebe5af82f",:disable_api_termination=>false,:image_id=>"ami-bd420e8d",:instance_initiated_shutdown_behavior=>"terminate",:instance_type=>"c3.large",:key_name=>"Beaker-jenkins-sector",:max_count=>1,:min_count=>1,:monitoring=>{:enabled=>true},:security_group_ids=>["sg-9f6926fa"],:subnet_id=>"subnet-92dd65f7") AWS::EC2::Errors::InsufficientInstanceCapacity We currently do not have sufficient c3.large capacity in the Availability Zone you requested (us-west-2b). Our system will be working on provisioning additional capacity. You can currently get c3.large capacity by not specifying an Availability Zone in your request or choosing us-west-2a, us-west-2c.
Failed: errored in CLI.provision
#<AWS::EC2::Errors::InsufficientInstanceCapacity: We currently do not have sufficient c3.large capacity in the Availability Zone you requested (us-west-2b). Our system will be working on provisioning additional capacity. You can currently get c3.large capacity by not specifying an Availability Zone in your request or choosing us-west-2a, us-west-2c.>

If we were not specifying an availability zone, it would have just picked one of the other zones that were under capacity (and we would have not seen the error). Since we need to have the subnet pinned in order to use VPCs Kenneth Barber has created a subnet in each of the regions. If we were able to specify a list of subnet ids and beaker was able to roll to the next subnet when one failed, it would give us the same ability as not specifying a vpc/subnet.

This change involves change Beaker to support a list of subnets, the failover code and updating PuppetDB to take advantage of that new subnet list feature.

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a)
Atlassian logo

Ryan Senior (JIRA)

unread,
Feb 25, 2015, 10:38:46 AM2/25/15
to puppe...@googlegroups.com
Ryan Senior updated an issue
Change By: Ryan Senior
Sprint: PuppetDB 2015-03- 11 25

Ryan Senior (JIRA)

unread,
Mar 11, 2015, 8:27:22 AM3/11/15
to puppe...@googlegroups.com
Ryan Senior updated an issue
Change By: Ryan Senior
Sprint: PuppetDB 2015-03-25

Ryan Senior (JIRA)

unread,
Mar 24, 2015, 9:41:02 AM3/24/15
to puppe...@googlegroups.com
Ryan Senior updated an issue
Change By: Ryan Senior
Sprint: PuppetDB 2015-04-08

Ryan Senior (JIRA)

unread,
Mar 24, 2015, 9:57:08 AM3/24/15
to puppe...@googlegroups.com
Ryan Senior updated an issue
Change By: Ryan Senior
Story Points: 5

Ryan Senior (JIRA)

unread,
Mar 24, 2015, 2:16:23 PM3/24/15
to puppe...@googlegroups.com
Ryan Senior updated an issue
Change By: Ryan Senior
Story Points: 8

Kenneth Barber (JIRA)

unread,
Mar 25, 2015, 12:01:06 PM3/25/15
to puppe...@googlegroups.com
Kenneth Barber updated an issue
Change By: Kenneth Barber
Fix Version/s: PDB 2.3.x

Steve Barlow (JIRA)

unread,
Mar 25, 2015, 12:02:29 PM3/25/15
to puppe...@googlegroups.com
Steve Barlow updated an issue
Change By: Steve Barlow
Sprint: PuppetDB 2015-04- 08 22

Rob Browning (JIRA)

unread,
Apr 8, 2015, 12:16:48 PM4/8/15
to puppe...@googlegroups.com
Rob Browning assigned an issue to Rob Browning
Change By: Rob Browning
Assignee: Rob Browning
This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
Atlassian logo

Rob Browning (JIRA)

unread,
Apr 9, 2015, 2:22:51 PM4/9/15
to puppe...@googlegroups.com
Rob Browning updated an issue
Using VPCs requires that we pin our instances to a specific subnet which also implies a specific availability zone. Under normal conditions this is fine, but when one availability zone is at capacity, it results in errors like the one below:

{noformat}

[AWS EC2 500 0.194905 0 retries] run_instances(:block_device_mappings=>[{:device_name=>"/dev/sda1",:ebs=>{:delete_on_termination=>true,:volume_size=>8}}],:client_token=>"35a3e6d2-119b-431b-94c1-7bcebe5af82f",:disable_api_termination=>false,:image_id=>"ami-bd420e8d",:instance_initiated_shutdown_behavior=>"terminate",:instance_type=>"c3.large",:key_name=>"Beaker-jenkins-sector",:max_count=>1,:min_count=>1,:monitoring=>{:enabled=>true},:security_group_ids=>["sg-9f6926fa"],:subnet_id=>"subnet-92dd65f7") AWS::EC2::Errors::InsufficientInstanceCapacity We currently do not have sufficient c3.large capacity in the Availability Zone you requested (us-west-2b). Our system will be working on provisioning additional capacity. You can currently get c3.large capacity by not specifying an Availability Zone in your request or choosing us-west-2a, us-west-2c.
Failed: errored in CLI.provision
#<AWS::EC2::Errors::InsufficientInstanceCapacity: We currently do not have sufficient c3.large capacity in the Availability Zone you requested (us-west-2b). Our system will be working on provisioning additional capacity. You can currently get c3.large capacity by not specifying an Availability Zone in your request or choosing us-west-2a, us-west-2c.>
{noformat}

If we were not specifying an availability zone, it would have just picked one of the other zones that were under capacity (and we would have not seen the error). Since we need to have the subnet pinned in order to use VPCs [~ken] has created a subnet in each of the regions. If we were able to specify a list of subnet ids and beaker was able to roll to the next subnet when one failed, it would give us the same ability as not specifying a vpc/subnet.

This change involves
 change  changing  Beaker to support a list of subnets, the failover code and updating PuppetDB to take advantage of that new subnet list feature.

Rob Browning (JIRA)

unread,
Apr 9, 2015, 7:33:48 PM4/9/15
to puppe...@googlegroups.com
Rob Browning updated an issue
Using VPCs requires that we pin our instances to a specific subnet which also implies a specific availability zone. Under normal conditions this is fine, but when one availability zone is at capacity, it results in errors like the one below:

{noformat}
[AWS EC2 500 0.194905 0 retries] run_instances(:block_device_mappings=>[{:device_name=>"/dev/sda1",:ebs=>{:delete_on_termination=>true,:volume_size=>8}}],:client_token=>"35a3e6d2-119b-431b-94c1-7bcebe5af82f",:disable_api_termination=>false,:image_id=>"ami-bd420e8d",:instance_initiated_shutdown_behavior=>"terminate",:instance_type=>"c3.large",:key_name=>"Beaker-jenkins-sector",:max_count=>1,:min_count=>1,:monitoring=>{:enabled=>true},:security_group_ids=>["sg-9f6926fa"],:subnet_id=>"subnet-92dd65f7") AWS::EC2::Errors::InsufficientInstanceCapacity We currently do not have sufficient c3.large capacity in the Availability Zone you requested (us-west-2b). Our system will be working on provisioning additional capacity. You can currently get c3.large capacity by not specifying an Availability Zone in your request or choosing us-west-2a, us-west-2c.
Failed: errored in CLI.provision
#<AWS::EC2::Errors::InsufficientInstanceCapacity: We currently do not have sufficient c3.large capacity in the Availability Zone you requested (us-west-2b). Our system will be working on provisioning additional capacity. You can currently get c3.large capacity by not specifying an Availability Zone in your request or choosing us-west-2a, us-west-2c.>
{noformat}

If we were not specifying an availability zone, it would have just picked one of the other zones that were under capacity (and we would have not seen the error). Since we need to have the subnet pinned in order to use VPCs [~ken] has created a subnet in each of the  regions  zones . If we were able to specify a list of subnet ids and beaker was able to roll to the next subnet when one failed, it would give us the same ability as not specifying a vpc/subnet.

This change involves changing Beaker to support a list of subnets, the failover code and updating PuppetDB to take advantage of that new subnet list feature.

Rob Browning (JIRA)

unread,
Apr 15, 2015, 5:42:01 PM4/15/15
to puppe...@googlegroups.com
Rob Browning commented on New Feature PDB-1263
 
Re: Round robin support for EC2 subnets

Currently waiting for preliminary team review.

Rob Browning (JIRA)

unread,
Apr 22, 2015, 7:52:57 PM4/22/15
to puppe...@googlegroups.com

Kenneth Barber (JIRA)

unread,
Apr 23, 2015, 6:12:00 AM4/23/15
to puppe...@googlegroups.com

I'm guessing this is meant to be "Ready for merge" not "Needs information" since its in review by the beaker team now?

Wyatt Alt (JIRA)

unread,
May 6, 2015, 5:17:19 PM5/6/15
to puppe...@googlegroups.com
Wyatt Alt commented on New Feature PDB-1263

I'm removing 2.3.x as a fix version here. I'll add it back in a bit later.

Wyatt Alt (JIRA)

unread,
May 6, 2015, 5:17:24 PM5/6/15
to puppe...@googlegroups.com
Wyatt Alt updated an issue
 
Change By: Wyatt Alt
Fix Version/s: PDB 2.3.x

Wyatt Alt (JIRA)

unread,
May 7, 2015, 8:18:26 PM5/7/15
to puppe...@googlegroups.com
Wyatt Alt updated an issue

replacing 2.3.x as the fix version.

Change By: Wyatt Alt
Fix Version/s: PDB 2.3.x
Add Comment Add Comment
 

Kurt Wall (JIRA)

unread,
May 19, 2015, 7:48:19 PM5/19/15
to puppe...@googlegroups.com
Kurt Wall updated an issue
Change By: Kurt Wall
QA Risk Assessment Reason: N/A for test infrastructure

Kurt Wall (JIRA)

unread,
May 19, 2015, 7:48:19 PM5/19/15
to puppe...@googlegroups.com
Kurt Wall updated an issue
Change By: Kurt Wall
QA Status: Reviewed

Claudia Petty (Jira)

unread,
Jun 21, 2023, 10:56:08 AM6/21/23
to puppe...@googlegroups.com
Claudia Petty updated an issue
Change By: Claudia Petty
Labels: new-feature
This message was sent by Atlassian Jira (v8.20.21#820021-sha1:38274c8)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages