`ore aws upload` does not override existing AMIs/snapshots about mantle

[arithx]

I agree that the --force flag isn't obvious in what it's doing, it requires additional context on what is actually being done under the hood for image uploads. Essentially that flag is currently only targeted at overwriting the S3 objects, this notably excludes snapshots & AMIs.

The process for uploading an image follows the flow: upload bits to S3 -> create a snapshot from S3 -> create AMI from snapshot. Both ore & plume have some extra code that allows it to re-use bits throughout to allow for idempotency.

AMI names are intended to be unique (although some of the AWS APIs don't/didn't respect that) and as such it makes sense that we might want to be able to create a new AMI with the same name (which would involve deleting both the AMI & the underlying snapshot).

The actual fix would probably look something like adding code inside of the ore aws upload command that when --force is specified checks if an AMI exists of the same name (using the FindImage method) and then deleting both the AMI & the underlying snapshot (the getImageSnapshotID method exists which can find the underlying snapshot for a given AMI). If the deletion of the snapshot fails then we would want to print a warning with the snapshot ID but continue (as it's possible for multiple AMIs to be using the same underlying snapshot), which means we'd also need to add a ore aws delete-snapshot command to allow users to be able to properly clean-up their AWS environment.

Is this something that is urgently needed for your current work or can you work around it for now (specifying a different AMI name will bypass it in the interim)?

[miabbott]

Is this something that is urgently needed for your current work or can you work around it for now (specifying a different AMI name will bypass it in the interim)?

Nope, not urgent, just a nice to have. Just something I've noticed while doing some testing and was looking for some context.

[cgwalters]

This behavior directly conflicts with cosa, since "failed" builds will reuse version numbers. See coreos/coreos-assembler#668

[arithx]

@cgwalters ah yeah, that's true.

I'll try to get some spare cycles in the next week or two to hack on it; if anyone would like to pick up the work I'd also be happy to review it and/or answer any questions.

[cgwalters]

PR in #1039