Aws-cli: cloud-formation validate-template example doesn't work

[glb]

The example command for cloud-formation validate-template uses --template-body to reference a local file:// URL, which doesn't work:

aws cloudformation validate-template --template-body file:./sample.template

A client error (ValidationError) occurred when calling the ValidateTemplate operation: Template format error: JSON not well-formed. (line 1, column 5)

I'm using aws-cli/1.8.1.

It looks from the rest of the docs that the example meant to be using template-url, which would also require using a URL pointing to an object in an AWS S3 bucket in the same region as the template.

[mtdowling]

--template-body is a valid way to supply a template. When using a local file URI, you must include file:// followed by your filename. What you have right now is not being picked up as a file URI because you have provided an invalid URI, which is being interpreted as a JSON document that has the contents file:./sample.template. Change your --template-body parameter to file://./sample.template and it will work.

[glb]

OK, thanks for clarifying!

[boompig]

This is unbelievably confusing and a very poor design choice.

While

aws cloudformation validate-template --template-body S3_Bucket.template

fails with the extremely cryptic error message

A client error (ValidationError) occurred when calling the ValidateTemplate operation: Template format error: unsupported structure.

The following command

aws cloudformation validate-template --template-body file://S3_Bucket.template --region us-west-1

succeeds.

In addition, the error message is extremely misleading, as it implies that parsing was attempted and failed, not that the document was not found/failed to be loaded.

There should either be

1. A more informative error message: for example requiring the protocol as a prefix and erring when one is not specified, or;
2. The --template-body argument should be interpreted as a local file URI by default.

[bamapookie]

@boompig That is because without the file URL syntax, the filename you entered is being evaluated as the template itself. The file name is not a valid JSON or YAML file. You could replace the filename in your first example with the actual JSON and it would evaluate it in place.

[washad]

@bamapookie But I hope you would agree that it wouldn't be difficult to look at the length of the argument and recognize that not to be the case and supply a more useful error message. Even a hint such as (did you forget to include 'file:') would be nice. The existing error message not only does nothing to let the user know what the real problem is but misleads her or him into thinking they have an invalid template -- which is arguably worse.

[boompig]

@bamapookie Thank you for your explanation.

the filename you entered is being evaluated as the template itself.

But why is that the case? This violates the logic assumption of the programmer using the interface.

Also, while your explanation helps explain the reason the observed behaviour occurs, it does not address:

• the uninformative error message, which does not help debug the problem for anyone who is unfamiliar with the command's internal workings
• the fact that this is a very unintuitive design. The fact that my initial comment has 41 +1's at the time of writing is a sign that this command's syntax needs changing

[C-Kenny]

This still occurs, although the issue is closed. The verification process still returns a ValidationError when file:// is omitted when passing in template file location.

[bamapookie]

@C-Kenny That is by design. The --template-body option receives the template body inline by default. You must specify the file:// prefix for the text to be recognized as a URI and load the resource, otherwise, the given text is assumed to be a JSON template and is processed as such, causing the JSON validation error in the original message.

[C-Kenny]

Thanks @bamapookie , I guess I was expecting a different parameter for passing in files, rather than prepending it with file://. It definitely took me by surprise, being new to CloudFormation too.

[bamapookie]

@C-Kenny I'm with you. I would prefer a different flag for specifying a file, but this works for me.

[KnightHawk3]

This decision makes perfect sense if you ignore how literally every single command line program works for the last 40 years.

So in other words, this is a head scratching decision. There should 100% be a file flag or it should just attempt once to parse it then see if the file exists.

[FeralRobot]

I just hit this issue also. The error message is very misleading, steering me to the structure of the yml file when actually the "file://" is missing

It's lucky I found this thread and went through the whole discussion

[moseskt]

Thank God for this thread, this almost got me stuck.