You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Class B subnet granularity is a lot for a single VPC. If one wants to preserve the option of VPC peering, then using less than a class B may be preferable.
Rather than basing everything off of one param:
CidrBlock: !Sub '10.${ClassB}.0.0/16'
Ideally one could add new params with defaults that provide the same behavior unless specified. However given that arithmetic expressions aren't supported, this implies some preprocessing, or a breaking change that uses different params all together.
The minimum number of params one would need are, I think:
To continue with that line of reasoning for a bit, one could do this with some pre-processing of the template, despite the lack of finesse. The custom resource thing just feels way to heavy handed for simple arithmetic (http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html)
Some level of validation to prevent illegal combinations wouldn't be bad either.
Is there an accepted templating format for yaml?
The text was updated successfully, but these errors were encountered:
Hi @bedge this is slightly related to #152 which will be fixed in v7. As soon as we have this merged, we can start working on your proposal. At the moment (v6), the ClassB parameter is used by other templates as well, so we don't have much flexibility here.
Re: vpc/vpc-*azs.yaml
Feature suggestion/guidelines for possible patch.
Class B subnet granularity is a lot for a single VPC. If one wants to preserve the option of VPC peering, then using less than a class B may be preferable.
Rather than basing everything off of one param:
Ideally one could add new params with defaults that provide the same behavior unless specified. However given that arithmetic expressions aren't supported, this implies some preprocessing, or a breaking change that uses different params all together.
The minimum number of params one would need are, I think:
To continue with that line of reasoning for a bit, one could do this with some pre-processing of the template, despite the lack of finesse. The custom resource thing just feels way to heavy handed for simple arithmetic (http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html)
Some level of validation to prevent illegal combinations wouldn't be bad either.
Is there an accepted templating format for yaml?
The text was updated successfully, but these errors were encountered: