Open adimarco opened 8 years ago
I've actually heard of this bug but have been unable to hunt it down since I don't have issues in my account. Can we blacklist an az name? I think cfn has enough control flow for that. Implicit assumption: az names are stable for a given account.
I think it would be better to just make the first parameter of that Select function be a parameter, so that it's value can be overridden when launching the stack.
From: Eric Price Sent: Friday, April 15, 9:18 PM Subject: Re: [DualSpark/cloudformation-environmentbase] Issues with HaCluster in pre-VPC accounts (#49) To: DualSpark/cloudformation-environmentbase
I've actually heard of this bug but have been unable to hunt it down since I don't have issues in my account. Can we blacklist an az name? I think cfn has enough control flow for that. Implicit assumption: az names are stable for a given account.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on https://github.com/DualSpark/cloudformation-environmentbase/issues/49#issuecomment-210732367 GitHubhttps://github.com/DualSpark/cloudformation-environmentbase/issues/49#issuecomment-210732367
I think blacklisting runs into complications because my us-east-1b isn't necessarily yours, and assuming that the AZ names are stable for a given account it becomes necessary to somehow determine the set of them that are valid for each account.
In the mean time, my solution was to just open a new account, but that may not be an option for some. I've still got the pre-VPC account if you guys want to test anything with it.
It appears that the Fn::GetAZs provided by Amazon returns some invalid output if it's run in an account that was created pre-VPC.
Specifically, it returns a list that includes AZs that can not create new subnets in the VPC era. This is relevant to environmentbase because Fn::GetAZs is used in generated templates when creating HaClusters (and probably other places)
Specifically, when deploying a template with an HaCluster in us-east-1 with an older account, the following snippet of generated template:
causes Cloudformation to explode with:
privateAZ1 Value (us-east-1b) for parameter availabilityZone is invalid. Subnets can currently only be created in the following availability zones: us-east-1e, us-east-1a, us-east-1d, us-east-1c.
Note - this ONLY occurs for pre-VPC accounts, due to the invalid AZ being returned. It appears that Amazon is aware of the issue but doesn't consider it a high priority to fix. http://stackoverflow.com/questions/22744467/vpc-capable-availability-zones-in-amazon/22812138#22812138
I'm not really sure what, if anything, can be done to fix this aside from building tables of VPC-subnet-capable AZs yourself instead of using Fn::GetAZs, but I thought you guys should be aware.