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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
