cfn-delete-stack was not ported over to the new aws-cli version

[jdrago999]

Is this on the todo list or was it excluded on purpose?

[jonaf]

Hi, this was not intentionally excluded. We didn't know if people were actually using it this way. Since previously, we were just shelling out to cfn-cmd, you could execute your template using any of the commands that cfn-cmd would take, even if we hadn't implemented it. Now that we're using the AWS Ruby SDK, however, we have to specifically enumerate and implement whatever commands we want to implement.

@temujin9 Any opinions on going back and supporting all of the cfn-cmd commands? It'd be pretty easy to do.

[temujin9]

It's an oversight on my part, I believe. Fixing it now.

[temujin9]

@jonaf Ah, I see what you mean. Yes, we should support all commands, unless it's unfeasible.

[jonaf]

Totally feasible. The cfn-cmd ones just passed "whatever" you did to cfn-cmd, which could result in obscure errors if you type the command incorrectly. Now, however, we have to actually implement each facet of the API we intend to support. However, it doesn't look like the usage ever purported that "any" command could be used, so I only implemented those API features that were expressly named in the usage.

[temujin9]

I think all the cfn-commands which pertain to a single stack should be supported, in some fashion. So "delete" and "cancel-update", and maybe a "describe" that rolls up the various "cfn-describe-*" calls into one coherently presented report.

I think we can skip the "cfn-list-*" calls, but I could be persuaded that they have value here, as well.

Everything else that we no longer support should also probably be explicitly caught and flagged as "already been deprecated", so there's no confusion on the end-user part. I doubt it will matter much, but I'd like the transition to be clean / obvious as possible. I'll get you a PR for that, momentarily.

[jdrago999]

Thank you! I've rolled back to v0.5.4 for now, but can't wait to get onto the new aws-cli version.

[temujin9]

@jonaf #52 addresses the deprecation flagging part of this.