feature request: Support EC2 capacity reservation creation and available-capacity transfers #67
AndreKurait
started this conversation in
Feature Requests (AWS)
Replies: 1 comment
|
Hi @AndreKurait, thanks for the detailed report. I have logged the four operations as a feature request in EC2. I will inform you once they are implemented. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Additional version check — 2026-10-08
Still blocked at the first
CreateCapacityReservationcall with the same unimplemented-action error. No reservation is created and the move branch is not reached, so no successful creation, move, or cancellation is claimed.The comparison used an unmodified
localstack/localstack-pro:2026.8.1Linux ARM64 image,repository digest
sha256:4aef81c531684570d7b3cfd2805afa02194c929d52bbeedabb7d4874798b1572.Vendor packages were
localstack-core 2026.8.1,moto-ext 5.1.48, and bundledboto3/botocore 1.43.78. HTTP probes used a separateboto3/botocore 1.43.101client; the process-local security-group probe used the bundled interpreter.
The same scripts were used, with no custom extensions or provider source changes.
Owned test containers and the disposable network were removed.
This is a second specifically tested version, not a claim to have tested the latest release.
Existing report search
I searched the LocalStack issue tracker and current organization Discussions for this operation and failure. I did not find an existing report for this exact reproduction.
Current behavior
The unmodified LocalStack reproduction is blocked at the first
CreateCapacityReservationcall, which returnsInternalFailure:The intended public-API flow creates two active, targeted, unlimited reservations in the same account and Availability Zone, both with
t3.micro,Linux/UNIX, and default tenancy. The source would have two unused instances of capacity and the destination one; it would then move one, leaving both records nonempty.No reservation was created and no move call was reached in this unmodified run. I am not claiming an independently reproduced move failure on this baseline. The attached script includes the requested follow-on transfer and idempotence checks for when creation is supported. Its empty cleanup list means there were no created records; it does not prove cancellation support.
No instances are launched, and no application workload or Docker guest is needed. The disposable LocalStack parent and its network were removed afterward.
Expected behavior
Support creation of these compatible capacity-reservation records, then moving one available unit from source to destination: total and available counts should change from
(2, 1)to(1, 2). Return the moved count and updated reservation records. Repeating the same client token should not transfer capacity twice. Finally, the caller should be able to cancel the records.References: CreateCapacityReservation and MoveCapacityReservationInstances.
This minimal request concerns unused capacity only. It does not require moving running instances, splitting a reservation, or testing automatic cancellation after moving all source capacity. I have not run the reproducer on live AWS.
Environment
localstack/localstack-pro:2026.7.5.sha256:0d74e1d2d7ce13a3cb25fc64cf15eb225f1c95c762e56e057bc6a9ed0ed29306.localstack-core 2026.7.5,moto-ext 5.1.46,moto.__version__ = 5.1.21.dev,boto3/botocore 1.43.51.This fresh Linux ARM64 run used a separate
boto3/botocore 1.43.101client and the unmodified pinned vendor image. The startup configuration matches the five ordinary API reproductions: DNS listener/default EC2-image downloads disabled, temporary state storage, no Docker socket or custom extension.Steps to reproduce
Start a disposable instance on a free loopback port:
Run the block in a disposable shell. Port 4567 must be free. The client needs
boto3; it uses only dummy credentials and a loopback endpoint. It creates disposable resources and cleans them up infinally; the shell trap removes the container even when the script reports failure. A nonzero exit is expected while the reported discrepancy is present. No Docker socket mount or application services are required.Complete standalone reproducer: ec2_move_capacity.py
All reactions