Hi all, from what I can tell after inspecting the code, these are the only AWS resources in master branch (if I haven't missed something) that have updatable properties that are not supported in AWS:
a) AWS::EC2::Volume - must not support any updates [1], size update is in master but not in stable/icehouse. Should we worry about deprecating it or simply move it to OS::Cinder::Volume? b) AWS::EC2::VolumeAttachment - must not support any updates [2], but is already in stable/icehouse. Must deprecate first. c) AWS::EC2::Instance - network_interfaces update is UpdateReplace in AWS [3], is already in master but not in stable/icehouse. The same question as for a) - do we have to worry or simply revert? d) AWS::CloudFormation::WaitCondition - that is a strange one. AWS docs state that no update is supported [4], but I get a feeling that some places in CI/CD are dependent on updatable bahaviour. With current effort of Steven Hardy to implement the native WaitConditions I think we could move update logic to native one and deprecate it in AWS resource. Also I am not quite clear if there is any difference in AWS docs between "Update requires: Replacement" and "Update requires: Updates are not supported". Can somebody give a hint on this? And a question on deprecation process - how should we proceed? I see it as create a bug, make warning log if resource is an AWS one and add a FIXME in the code to remember to move it two releases later. Would like to hear your comments. Best regards, Pavlo. [1] http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-ebs-volume.html#cfn-ec2-ebs-volume-size [2] http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-ebs-volumeattachment.html [3] http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-instance.html#cfn-ec2-instance-networkinterfaces [4] http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-waitcondition.html On Tue, Jul 8, 2014 at 12:05 AM, Steve Baker <sba...@redhat.com> wrote: > 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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
