Changing the subnet_id on a running instance does not replace the instance

[FrankelJb]

The documentation for CloudFormation indicates how the instance should be handled on updating the subnet_id. The instance should be replaced by a new instance. However, when using chef-provisioning-aws this does not happen. The chef-provisioning-aws module shows the new subnet_id when executing but it does not change the subnet_id on the running instance, nor does it replace the instance. Please advise.

[tyler-ball]

Hey @FrankelJb - thanks for filing this bug. I think there are a couple fixes we should do.

First, if a user changes the subnet of an instance (or some other un-updatable property like availability zone) we should either

1. Raise an error stating that this isn't currently possible
2. Provision a new instance and shutdown the old one

#2 is much more complicated than #1 because it brings up questions of deploy strategies - is this a blue/green deploy? Is it a fault tolerant cluster that can have members drop in and out? Is there a pre-shutdown hook we need to run?

In the short term I think we should implement #1 - this would at least allow users to run their own action [:destroy, :create]

[tyler-ball]

Talked with the team. This is our current plan.

1. Update the machine and load_balancer resource to raise an error if a user tries to update an attribute which would initiate a Replacement from the CloudFormation API.
2. Provide documentation on how to use the action [:destroy, :create] to replace the machine or load balancer like CloudFormation would. It should be something easy like

machine 'test' do
  machine_options {...}
  if update_requires_replacement?
    action [:destroy, :create]
  else
    action :create
  end
end

@FrankelJb Would that work for your purposes? I don't want to automatically make the resource recreate if an un-updatable attribute has changed because I think that could introduce unexpected outtages.

[FrankelJb]

Hi Tyler,

Thanks, that solution is sufficient. As long as the provisioning doesn't fail silently if the resource needs to be recreated. The only concern is that a user may forget to recreate the resource if there is no visible exception. But this solution that you've provided empowers the user, so thanks again.