0
votes

we're encountering a strange issue with AWS CloudFormation.

We're using CloudFormation in order to automate the deployment of some our machines; our CloudFormation yml describes the deployment, which contains a persistent EBS volume which was created outside the stack, and we don't want to remove or recreate along such stack (it contains a lot of the state of our application).

The relevant CloudFormation yml snippet is:

DataVolumeAttachment01: Type: AWS::EC2::VolumeAttachment Properties: Device: "/dev/xvdm" InstanceId: !Ref EC2Instance01 VolumeId: !Ref DataVolumeId EC2Instance01: Type: "AWS::EC2::Instance" Properties: ImageId: "ami-6f587e1c" KeyName: !Ref "KeyName" InstanceType: !Ref "InstanceType" BlockDeviceMappings: # Root device - DeviceName: "/dev/sda1" Ebs: VolumeType: "gp2" DeleteOnTermination: "true" VolumeSize: 20

So, the root device is "transient" (every time the stack is updated, such volume is deleted and gets reprovisioned with userdata), while /dev/xvdm should contain our persistent data; such device gets mounted at the end of the userdata, and added to fstab.

Following AWS own documentation, I created a script that unmounts such volume from inside the VM, and I even tried deattaching such volume from the EC2 Instance, something like:

${SSH_CMD} "cd /home/application && application stop && sudo umount /data && echo data volume unmounted" echo "detaching data volume" VOLID=$(aws ec2 describe-volumes --filters Name=tag-key,Values="Name" Name=tag-value,Values=persistent-volume --query 'Volumes[*].{ID:VolumeId}' --output text) aws ec2 detach-volume --volume-id "${VOLID}"

I have verified the umount and the detach succeed.

The creation of a new stack with my template and parameters succeeds.

And yet, when I launch

aws cloudformation update-stack --capabilities CAPABILITY_IAM --stack-name $STACK_NAME --template-body file://single_ec2_instance.yml --parameters file://$AWS_PARAMETERS_FILE

The update fails, with this error:

Update to resource type AWS::EC2::VolumeAttachment is not supported.

Even though I'm not changing anything within such resource.

What's up? How can I solve or work around?

1

1 Answers

0
votes

It seems that the thing was a non-issue.

Either CloudFormation is influenced by exhausted t2 cpu credits (which we had exhausted, we were trying to change the instance type for that exact reason in order to use m3 or m4) or we got a bad day for EC2/CloudFormation in Ireland. Today, with the same exact setup, every update succeeded.