Open Stack

On 07/07/14 20:37, Steven Hardy wrote:
> Hi all,
>
> Recently I've been adding review comments, and having IRC discussions about
> changes to update behavior for CloudFormation compatible resources.
>
> In several cases, folks have proposed patches which allow non-destructive
> update of properties which are not allowed on AWS (e.g which would result
> in destruction of the resource were you to run the same template on CFN).
>
> Here's an example:
>
> https://review.openstack.org/#/c/98042/
>
> Unfortunately, I've not spotted all of these patches, and some have been
> merged, e.g:
>
> https://review.openstack.org/#/c/80209/
>
> Some folks have been arguing that this minor deviation from the AWS
> documented behavior is OK.  My argument is that is definitely is not,
> because if anyone who cares about heat->CFN portability develops a template
> on heat, then runs it on CFN a non-destructive update suddenly becomes
> destructive, which is a bad surprise IMO.
>
> I think folks who want the more flexible update behavior should simply use
> the native resources instead, and that we should focus on aligning the CFN
> compatible resources as closely as possible with the actual behavior on
> CFN.
>
> What are peoples thoughts on this?
>
> My request, unless others strongly disagree, is:
>
> - Contributors, please check the CFN docs before starting a patch
>   modifying update for CFN compatible resources
> - heat-core, please check the docs and don't approve patches which make
>   heat behavior diverge from that documented for CFN.
>
> The AWS docs are pretty clear about update behavior, they can be found
> here:
>
> http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html
>
> The other problem, if we agree that aligning update behavior is desirable,
> is what we do regarding deprecation for existing diverged update behavior?
>
I've flagged a few AWS incompatible enhancements too.

I think any deviation from AWS compatibility should be considered a bug.
For each change we just need to evaluate whether users are depending on
a given non-AWS behavior to decide on a deprecation strategy.

For update-able properties I'd be inclined to just fix them. For
heat-specific properties/attributes we should flag them as deprecated
for a cycle and the deprecation message should encourage switching to
the native heat resource.