Avoid cn-north-1d #3920
Avoid cn-north-1d #3920
Conversation
| @@ -93,7 +93,9 @@ type AvailabilityZoneSelector struct { | |||
| // NewSelectorWithDefaults create a new AvailabilityZoneSelector with the | |||
| // default selection strategy and usage rules | |||
| func NewSelectorWithDefaults(ec2api ec2iface.EC2API) *AvailabilityZoneSelector { | |||
| avoidZones := map[string]bool{} | |||
| avoidZones := map[string]bool{ | |||
| "cn-north-1d": true, | |||
There was a problem hiding this comment.
The problem here is that availability zone names are not fixed and are in fact randomized during account creation (see details here: https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html).
While all existing accounts will have the new zone with "d" letter simply because other zones were already taken when new zone was added, new accounts may not necessarily have the new zone with "d" letter, and may instead experience problem on zone "cn-north-1a" for example.
The correct approach would be to perform ec2:DescribeAvailabilityZones call, find out which zone has ID "cnn1-az4" (zone IDs are not random), and get the name of the zone with that ID.
There was a problem hiding this comment.
@artem-nefedov you're right, thanks for the heads-up. We do not have access to Beijing so I can't verify if the offending zone ID is cnn1-az4. Can you confirm that you have verified this information?
There was a problem hiding this comment.
@cPu1 Yes, can confirm:
{
"State": "available",
"OptInStatus": "opt-in-not-required",
"Messages": [],
"RegionName": "cn-north-1",
"ZoneName": "cn-north-1d",
"ZoneId": "cnn1-az4",
"GroupName": "cn-north-1",
"NetworkBorderGroup": "cn-north-1",
"ZoneType": "availability-zone"
}
Description
Still technically the "wrong thing" to do, since eksctl already provides a way for users to not use AZs, but I don't believe this will get fixed upstream for a very very long time, and it is guaranteed to be forgotten/not read by at least some users.
🤷♀️