On 08/07/14 08:06, Pavlo Shchelokovskyy wrote:
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:
Many thanks for doing this audit Pavlo! :)
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?
I'd say we can just start raising errors on update (see below) now.
b) AWS::EC2::VolumeAttachment - must not support any updates [2], but is
already in stable/icehouse. Must deprecate first.
Agree.
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?
Just revert IMO.
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.
Agree.
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?
I believe there must be a difference. The "Updates are not supported"
thing actually appears to be a recent improvement to their docs - when I
looked before they didn't say anything about those resources, which was
pretty ambiguous. I just assumed that they actually worked, but it
appears that any attempt to update them will be treated as an error.
(That makes some sense... replace on update is basically never the
correct semantics for e.g. a volume.)
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.
+1
cheers,
Zane.
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
<mailto: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
<mailto: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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
