Open Stack

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 <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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140708/d8f5e146/attachment.html>