Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AWS AMI resources #2784

Merged
merged 1 commit into from
Sep 4, 2015
Merged

AWS AMI resources #2784

merged 1 commit into from
Sep 4, 2015

Conversation

apparentlymart
Copy link
Contributor

Three new resources for the AWS provider to support the three different methods of creating an AMI:

  • aws_ami, using RegisterImage to directly set the various AMI attributes.
  • aws_ami_copy, using CopyImage to duplicate an AMI that is possibly in another region
  • aws_ami_from_instance, using CreateImage to produce an AMI fashioned after an active or stopped EC2 instance that uses an EBS filesystem

Other tasks:

  • Acceptance Tests
  • Documentation

@apparentlymart
Copy link
Contributor Author

This now has acceptance tests for the aws_ami_copy and aws_ami_from_instance resources. Exercising aws_ami itself requires the existence of an EBS snapshot and there isn't yet a resource for creating those, so all we have for now is a FIXME comment noting that we should come back and write an acceptance test once an aws_ebs_snapshot resource is implemented.

aws_ami_copy is the one with the most obvious use-case here: taking an AMI in one region and copying it to another.

aws_ami_from_instance is obviously dependent on having an instance in a good state for a snapshot, which is a hard thing for Terraform alone to arrange. It found utility in my prototype described in #2789, though.

aws_ami will find its most obvious purpose once an aws_ebs_snapshot_copy resource is available, as a way to fake copying AMIs from one account to another by copying the snapshots and creating a fresh AMI from them.

AWS provides three different ways to create AMIs that each have different
inputs, but once they are complete the same management operations apply.

Thus these three resources each have a different "Create" implementation
but then share the same "Read", "Update" and "Delete" implementations.
@phinze
Copy link
Contributor

phinze commented Sep 4, 2015

This looks really great, @apparentlymart!

The 3-resources-with-shared-impl model you chose ends up working out very nicely I think. The fact that you only have to implement different Create methods for each resource makes a lot of sense given the relationship between the three.

Totally understandable that we can't AccTest aws_ami yet. I think this looks good to pull in as-is. Amazing work as usual! 😀

phinze added a commit that referenced this pull request Sep 4, 2015
@phinze phinze merged commit 3abf479 into hashicorp:master Sep 4, 2015
@stack72 stack72 mentioned this pull request Sep 7, 2015
@apparentlymart apparentlymart deleted the aws-images branch September 9, 2015 00:31
@ghost
Copy link

ghost commented May 1, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators May 1, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants