Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with HaCluster in pre-VPC accounts #49

Open
adimarco opened this issue Apr 16, 2016 · 3 comments
Open

Issues with HaCluster in pre-VPC accounts #49

adimarco opened this issue Apr 16, 2016 · 3 comments

Comments

@adimarco
Copy link
Contributor

adimarco commented Apr 16, 2016

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:

 "privateAZ1": {
            "Properties": {
                "AvailabilityZone": {
                    "Fn::Select": [
                        1,
                        {
                            "Fn::GetAZs": ""
                        }
                    ]
                },

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.

@gimballock
Copy link
Contributor

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.

@sesas
Copy link
Contributor

sesas commented Apr 16, 2016

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 #49 (comment) GitHubhttps://github.com//issues/49#issuecomment-210732367

@adimarco
Copy link
Contributor Author

adimarco commented Apr 17, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants