<div dir="ltr"><div>Hi all,</div><div><br></div><div>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:<br>
</div><div>
<br></div><div>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?</div><div><br></div>
<div>b) AWS::EC2::VolumeAttachment - must not support any updates [2], but is already in stable/icehouse. Must deprecate first.</div><div><br></div><div>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?</div>
<div><br></div><div>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.</div>
<div><br></div><div>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?</div>
<div><br></div><div>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.</div>
<div><br></div><div>Would like to hear your comments.</div><div><br></div><div>Best regards,</div><div>Pavlo.</div>
<div><br></div><div>[1] <a href="http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-ebs-volume.html#cfn-ec2-ebs-volume-size" target="_blank">http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-ebs-volume.html#cfn-ec2-ebs-volume-size</a></div>
<div>[2] <a href="http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-ebs-volumeattachment.html" target="_blank">http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-ebs-volumeattachment.html</a></div>
<div>[3] <a href="http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-instance.html#cfn-ec2-instance-networkinterfaces" target="_blank">http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-instance.html#cfn-ec2-instance-networkinterfaces</a></div>
<div>[4] <a href="http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-waitcondition.html" target="_blank">http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-waitcondition.html</a></div>
<div>
<br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 8, 2014 at 12:05 AM, Steve Baker <span dir="ltr"><<a href="mailto:sbaker@redhat.com" target="_blank">sbaker@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 07/07/14 20:37, Steven Hardy wrote:<br>
> Hi all,<br>
><br>
> Recently I've been adding review comments, and having IRC discussions about<br>
> changes to update behavior for CloudFormation compatible resources.<br>
><br>
> In several cases, folks have proposed patches which allow non-destructive<br>
> update of properties which are not allowed on AWS (e.g which would result<br>
> in destruction of the resource were you to run the same template on CFN).<br>
><br>
> Here's an example:<br>
><br>
> <a href="https://review.openstack.org/#/c/98042/" target="_blank">https://review.openstack.org/#/c/98042/</a><br>
><br>
> Unfortunately, I've not spotted all of these patches, and some have been<br>
> merged, e.g:<br>
><br>
> <a href="https://review.openstack.org/#/c/80209/" target="_blank">https://review.openstack.org/#/c/80209/</a><br>
><br>
> Some folks have been arguing that this minor deviation from the AWS<br>
> documented behavior is OK. My argument is that is definitely is not,<br>
> because if anyone who cares about heat->CFN portability develops a template<br>
> on heat, then runs it on CFN a non-destructive update suddenly becomes<br>
> destructive, which is a bad surprise IMO.<br>
><br>
> I think folks who want the more flexible update behavior should simply use<br>
> the native resources instead, and that we should focus on aligning the CFN<br>
> compatible resources as closely as possible with the actual behavior on<br>
> CFN.<br>
><br>
> What are peoples thoughts on this?<br>
><br>
> My request, unless others strongly disagree, is:<br>
><br>
> - Contributors, please check the CFN docs before starting a patch<br>
> modifying update for CFN compatible resources<br>
> - heat-core, please check the docs and don't approve patches which make<br>
> heat behavior diverge from that documented for CFN.<br>
><br>
> The AWS docs are pretty clear about update behavior, they can be found<br>
> here:<br>
><br>
> <a href="http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html" target="_blank">http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html</a><br>
><br>
> The other problem, if we agree that aligning update behavior is desirable,<br>
> is what we do regarding deprecation for existing diverged update behavior?<br>
><br>
</div></div>I've flagged a few AWS incompatible enhancements too.<br>
<br>
I think any deviation from AWS compatibility should be considered a bug.<br>
For each change we just need to evaluate whether users are depending on<br>
a given non-AWS behavior to decide on a deprecation strategy.<br>
<br>
For update-able properties I'd be inclined to just fix them. For<br>
heat-specific properties/attributes we should flag them as deprecated<br>
for a cycle and the deprecation message should encourage switching to<br>
the native heat resource.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>