The CloudFormation Resource Schema defines the shape and semantic for resources provisioned by CloudFormation. It is used by provider developers using the CloudFormation RPDK.
Apache License 2.0
90
stars
38
forks
source link
Obfuscated schema validation messages make resolution cumbersome #127
Troubleshooting schema validation errors is cumbersome and should be more customer focused.
While troubleshooting a resource being provisioned the builder is left trying to figure out a few things. Based on the scrubbed messaging the user has to:
Determine what resource failed and its type
Run describe type on the type specified
Relate the error message, the properties of the resource, and the json schema definition to determine the correct pattern. When the definition names don't match property names this can become more difficult. When there are many layers of sub properties this can become more annoying. And when the value is a Ref/GetAtt to another resource its even more difficult to understand and translate what went wrong.
Example CloudFormation validation failure:
Model validation failed (#/KmsKeyId: failed validation constraint for keyword [pattern])
Example failure when calling the service itself (Lambda example):
1 validation error detected: Value 'NotAArn' at 'kMSKeyArn' failed to satisfy constraint: Member must satisfy regular expression pattern: (arn:(aws[a-zA-Z-]*)?:[a-z0-9-.]+:.*)|()
Obfuscated messaging was added by #40
I can understand not printing the value with secretsmanager dynamic references but we should at least be able to provide a path to the error and what is allowed (pattern, min/max length, etc.). This would eliminate so many of the above steps.
Also the layering of these error messages can make troubleshooting harder. This may be a documentation thing but took me a few times looking at the errors above to understand if the error was coming from CloudFormation or form the service itself. In this scenario the error coming from the service was more detailed and allowed me to resolve the issue quicker than the CloudFormation error but I'm not sure that is always the case.
Troubleshooting schema validation errors is cumbersome and should be more customer focused.
While troubleshooting a resource being provisioned the builder is left trying to figure out a few things. Based on the scrubbed messaging the user has to:
Example CloudFormation validation failure:
Model validation failed (#/KmsKeyId: failed validation constraint for keyword [pattern])Example failure when calling the service itself (Lambda example):
1 validation error detected: Value 'NotAArn' at 'kMSKeyArn' failed to satisfy constraint: Member must satisfy regular expression pattern: (arn:(aws[a-zA-Z-]*)?:[a-z0-9-.]+:.*)|()Obfuscated messaging was added by #40
I can understand not printing the value with secretsmanager dynamic references but we should at least be able to provide a path to the error and what is allowed (pattern, min/max length, etc.). This would eliminate so many of the above steps.
Also the layering of these error messages can make troubleshooting harder. This may be a documentation thing but took me a few times looking at the errors above to understand if the error was coming from CloudFormation or form the service itself. In this scenario the error coming from the service was more detailed and allowed me to resolve the issue quicker than the CloudFormation error but I'm not sure that is always the case.