aws-cloudformation / aws-cloudformation/cloudformation-coverage-roadmap
AWS::ECS::Volume should support update of `SnapshotId` with a volume replacement
- Dominant language
- No language data
- Stars
- 1.1k
- Forks
- 62
- PR merge metrics
- No merged PRs in 30d
Description
### Name of the resource
AWS::EC2::Volume
### Resource name
_No response_
### Description
Currently, AWS::EC2::Volume disallows any update to SnapshotId. This should be supported with the volume replaced whenever the SnapshotId changed.
The reason being Cloud Formation should support a workflow that makes the recovery from an EBS snapshot reasonably easy.
Unfortunately, this is not the case right now. Recovery from an EBS snapshot currently involves two stack updates chronologically.
1. Update the stack with the existing AWS::EC2::Volume and AWS::EC2::VolumeAttach resources removed
2. Update the stack by re-adding a new AWS::EC2::Volume with the target SnapshotId and its corresponding AWS::EC2::VolumeAttach resource.
Combining the two steps into a single step does not work.
1. For one, this requires a change to the volume's logical id to something different than the existing one. This breaks the semantics of the resource's logical name.
2. Secondly, I don't have any control over the device name for the nvme disk (i.e. /dev/nvme1n1) since the naming of nvme EBS volumes is based on their order of attachment. I can't control whether the detachment of the existing or the attachment of the new volume will happen first. This causes all sorts of additional headaches. How do you partition and format the volume without knowing its device name first? So some extra probing will be required to figure out the current device name.
Even when this does work, please remember a workaround is just a workaround. Your customers use your product to make their life easier, the workaround does not deliver that.
All in all, a key selling point of Cloud Formation is it's declarative. But in this case, I can't simply declare a desired state and call it a day. Rather I am forced to use a declarative tool to mimic some procedural changes.
Allowing an EBS volume to update its SnapshotId in Cloudformation will significantly improve its usability making it work much much nicer with EBS snapshot.
### Other Details
_No response_
Contributor guide
Research direction
Start by reconciling the title's AWS::ECS::Volume reference with the body, which requests AWS::EC2::Volume support for changing SnapshotId. Review the existing CloudFormation coverage-roadmap entry and determine how replacement semantics are recorded for this resource. Done means the requested SnapshotId update and volume replacement behavior are clearly captured for consideration.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws
- Domain
- cloud
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100