AWS instance must not support NICS in-place update

[Pavlo Shchelokovskyy]

According to AWS docs AWS::EC2::Instance supports updates to "NetworkInterfaces" and "SubnetId" properties only in UpdateReplace manner [1] but we have it accepting in-place updates in our AWS-compatible resource [2].

In light of ML discussion [3] our resource must be brought in accordance with AWS docs. As the change to AWS-compatible Heat resource was merged after Icehouse release, it involves simply reverting that change.

[1] http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-instance.html
[2] https://github.com/openstack/heat/blob/master/heat/engine/resources/instance.py#L229
[3] http://lists.openstack.org/pipermail/openstack-dev/2014-July/039429.html

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/105992

[OpenStack Infra (hudson-openstack)]

Change abandoned by Pavlo Shchelokovskyy (<email address hidden>) on branch: master
Review: https://review.openstack.org/105992
Reason: After some thinking I reconsidered and tend to agree with huangtianhua - some update is better then none. The problem is that in order to align with AWS we need somehow first delete the old instance, create a similar one and stick it in the dependency tree at the same place. Needs more thought.

[Pavlo Shchelokovskyy (pshchelo)]

I am thinking about a following approach to tackle this discrepancy - if NICS (or Subnet?) are specified, in handle_update detach all the NICS and then raise UpdateReplace. The downside is that it makes 'update_allowed' for those properties effectively a noop, that might lead to some confusion (even with help strings for properties amended to describe this particular behavior).

Would such approach be acceptable?

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/108002

[OpenStack Infra (hudson-openstack)]

Change abandoned by Pavlo Shchelokovskyy (<email address hidden>) on branch: master
Review: https://review.openstack.org/108002
Reason: better to be better than AWS instead of strict consistency