E3012 Property Type Checks are Too Strict

[phene]

cfn-lint version: 0.9.2

There are many properties that demand a "String" type when they are integer in nature. Here are examples:

• AWS::AutoScaling::AutoScalingGroup/Properties/DesiredCapacity
• AWS::AutoScaling::AutoScalingGroup/Properties/MaxSize
• AWS::AutoScaling::AutoScalingGroup/Properties/MinSize
• AWS::Route53::RecordSet/Properties/TTL

This list is actually pretty huge, which is why I haven't wanted to create an override spec. Since these are all accepted as numbers by CloudFormation, we should be able to treat that as such.

[kddejong]

@cmmeyer may be able to shed some light on why one is picked over the other as I think it can be pretty random at times. I think there are even cases where something like port will be string or int depending on the resource.

This is related to an earlier discussion #42. At the time of that discussion there was an issue where CloudFormation wouldn't convert an int to a string. I retested that scenario tonight and it looks like that has been fixed. The original concern is that CloudFormation didn't always convert between types and we didn't have any idea of where we could trust it to the needful or when it would fail. So it was easier to stick to the spec and force that type.

Originally cfn-lint would would try convert a string to an int if an int was required but a string was provided. The annoying part as you describe is that if the type is string we wouldn't know to try and convert it. Which brings up a great discussion to this topic. If the spec asks for a string where it can only be an int why wouldn't we just make it an int.

To be clear on what your desired outcome is...

1. Is that those values should really be of type integer (not of type string)
2. that cfn-lints type checking is to strict and needs to be relaxed
3. Or maybe a combination of both

[fatbasstard]

More information here: https://github.com/awslabs/cfn-python-lint/blob/master/docs/cfn-resource-specification.md#valueprimitivetype

There indeed are "weird" types indeed, but that's all in the Specification files. If the Spec files specifies a type is a String, it has to be a String

[fatbasstard]

There are many properties that demand a "String" type when they are integer in nature.

I consider this an assumption. We're working with automated systems. In these systems the specification/API tells what the type of a property is. This might go against personal feelings or ideas, but that is not the issue. If an API expects a String, the value is a String... Even if the names gives a feeling that it should be a different type....

Besides, consider the fact that maybe it's on purpose. Maybe the Cfn team is planning on support TTL in a "5h" format 🤔

[phene]

If the team is unwilling to deviate from the spec definitions, then perhaps loosen the restriction to check if the type can be coerced into a string. That is certainly the case for things like integers and booleans, which CloudFormation does today. That wouldn't be the case if it's an array or a hash.

[kddejong]

@phene we are debating a methodology to configure rules which would include a way to turn off strict type checking for this rule. I'll update this issue based on what we figure out.

[phene]

Any news on this?

[kddejong]

Sorry for the delay. I'm waiting on the pull request to get merged and then you should be able to configure this rule to turn off the strict checking.

[kddejong]

Fixed with release v0.20.0. See https://github.com/aws-cloudformation/cfn-python-lint#configure-rules for more information.

[andrew-glenn]

Looks like the CFN API has started to enforce more strict type checking.

This used to work, it currently passes lint, but the CFN API kicks it back.

Parameter:
  Type: String
  Default: true
  AllowedValues:
     - true
     - false

The same parameter needs to be formatted as below, for the CFN API to be happy.

Parameter:
  Type: String
  Default: ‘true'
  AllowedValues:
     - ‘true'
     - ‘false'

Just an FYI to all concerned. I'm sure there are other strict-type situations similar to this.

[PatMyron]

E3016 for UpdatePolicy and E1024 for Fn::Cidr are similar as well:

cfn-lint/src/cfnlint/rules/resources/updatepolicy/Configuration.py

Line 128 in 1a6657b

default_message = 'Value for {0} must be of type {1}'

#2453

[kddejong]

I'm going to pick this one back up. @PatMyron do you believe we should change the default of this rule to not be strict?

[kddejong]

As of version v0.54.0 the default is to not be strict