Open Stack

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