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

providers/aws: add root_block_device to aws_instance #998

Merged
merged 1 commit into from
Feb 18, 2015

Conversation

phinze
Copy link
Contributor

@phinze phinze commented Feb 18, 2015

AWS provides a single BlockDeviceMapping to manage three different
kinds of block devices:

(a) The root volume
(b) Ephemeral storage
(c) Additional EBS volumes

Each of these types has slightly different semantics [1].

(a) The root volume is defined by the AMI; it can only be customized
with volume_size, volume_type, and delete_on_termination.

(b) Ephemeral storage is made available based on instance type [2]. It's
attached automatically if no block device mappings are specified, and
must otherwise be defined with block device mapping entries that contain
only DeviceName set to a device like "/dev/sdX" and VirtualName set to
"ephemeralN".

(c) Additional EBS volumes are controlled by mappings that omit
virtual_name and can specify volume_size, volume_type,
delete_on_termination, snapshot_id, and encryption.

After deciding to ignore root block devices to fix #859, we had users
with configurations that were attempting to manage the root block device chime
in on #913.

Terraform does not have the primitives to be able to properly handle a
single collection of resources that is partially managed and partially
computed, so our strategy here is to break out logical sub-resources for
Terraform and hide the BlockDeviceMapping inside the provider
implementation.

Now (a) is supported by the root_block_device sub-resource, and (b)
and (c) are still both merged together under block_device, though I
have yet to see ephemeral block devices working properly.

Looking into possibly separating out ephemeral_block_device and
ebs_block_device sub-resources as well, which seem like the logical
next step. We'll wait until the next big release for this, though, since
it will break backcompat.

[1] http://bit.ly/ec2bdmap
[2] http://bit.ly/instancestorebytype

Fixes #913

Optional: true,
Default: true,
ForceNew: true,
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this at the bottom? /nitpick.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't see a coherent order. You'd prefer alphabetical?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH I'd prefer alphabetical, but that's prolly a separate PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OH I can at least alphabetize the sub-schema. 👍

@mitchellh
Copy link
Contributor

This all looks great. Unifying them internally is pretty clever. I'd say 👍 to this.

@phinze phinze force-pushed the f-aws-instance-root-block-device branch from 2142527 to 93586fc Compare February 18, 2015 19:07
@phinze phinze changed the title [WIP] providers/aws: add root_block_device to aws_instance providers/aws: add root_block_device to aws_instance Feb 18, 2015
AWS provides a single `BlockDeviceMapping` to manage three different
kinds of block devices:

 (a) The root volume
 (b) Ephemeral storage
 (c) Additional EBS volumes

Each of these types has slightly different semantics [1].

(a) The root volume is defined by the AMI; it can only be customized
with `volume_size`, `volume_type`, and `delete_on_termination`.

(b) Ephemeral storage is made available based on instance type [2]. It's
attached automatically if _no_ block device mappings are specified, and
must otherwise be defined with block device mapping entries that contain
only DeviceName set to a device like "/dev/sdX" and VirtualName set to
"ephemeralN".

(c) Additional EBS volumes are controlled by mappings that omit
`virtual_name` and can specify `volume_size`, `volume_type`,
`delete_on_termination`, `snapshot_id`, and `encryption`.

After deciding to ignore root block devices to fix #859, we had users
with configurations that were attempting to manage the root block device chime
in on #913.

Terraform does not have the primitives to be able to properly handle a
single collection of resources that is partially managed and partially
computed, so our strategy here is to break out logical sub-resources for
Terraform and hide the BlockDeviceMapping inside the provider
implementation.

Now (a) is supported by the `root_block_device` sub-resource, and (b)
and (c) are still both merged together under `block_device`, though I
have yet to see ephemeral block devices working properly.

Looking into possibly separating out `ephemeral_block_device` and
`ebs_block_device` sub-resources as well, which seem like the logical
next step. We'll wait until the next big release for this, though, since
it will break backcompat.

[1] http://bit.ly/ec2bdmap
[2] http://bit.ly/instancestorebytype

Fixes #913
Refs #858
@phinze phinze force-pushed the f-aws-instance-root-block-device branch from 93586fc to 73d20b4 Compare February 18, 2015 19:15
phinze added a commit that referenced this pull request Feb 18, 2015
providers/aws: add root_block_device to aws_instance
@phinze phinze merged commit 1aebf54 into master Feb 18, 2015
@phinze phinze deleted the f-aws-instance-root-block-device branch February 18, 2015 19:31
@ghost
Copy link

ghost commented May 4, 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 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
2 participants