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: Validate IOPs for EBS Volumes #4146

Merged
merged 3 commits into from
Dec 15, 2015
Merged

Conversation

catsby
Copy link
Contributor

@catsby catsby commented Dec 2, 2015

IOPs must be an integer.
The range varies by instance size (docs here)pl, so we simply validate that it's an integer.
IOPs is also not valid for any type that is not io1. Unfortunately I don't believe we can check for that in the plan phase, but we validate that in the apply phase here

Also, a minor fix to the docs: us-west-1a does not exist

helping

@catsby
Copy link
Contributor Author

catsby commented Dec 2, 2015

Fixes #4146 #2298

@billputer
Copy link

Just to clarify, does this still allow passing in a false value to iops?

Currently we have a module that accepts two arguments: storage_type and iops. We use this with both gp2 and io1. For example:

storage_type = "gp2"
iops = false

storage_type = "io1"
iops = 200

Basically we need our module to accept both gp2 and io1 storage types. My intuition is that d.GetOk("iops") will return the "false" value and fail validation.

@catsby
Copy link
Contributor Author

catsby commented Dec 3, 2015

Just to clarify, does this still allow passing in a false value to oops?

Sorry, no :(

iops is an integer value. Passing false doesn't fit here. As the PR stands, supplying iops with type of gp2 will result in an error. But maybe it should just ignore the iops and log a warning? cc @phinze / @jen20 for thoughts on that

@billputer
Copy link

The underlying problem that I'm dealing with is that there's I haven't found away in Terraform to conditionally set an argument in a module. That is, only set the "iops" if it's passed in to the module. You can't allow both (storage_type = gp2) and (storage_type = io1, iops = 200).

That's more an issue with Terraform than it is with this PR, which does the sensible thing. Unfortunately it probably means I'll have to have two modules, one for gp2 and one for io1, unless I can find a better workaround.

@phinze
Copy link
Contributor

phinze commented Dec 4, 2015

@catsby I think the zero value here can just skip the validation so that this would work:

storage_type = "gp2"
iops = 0

storage_type = "io1"
iops = 200

I'd actually expect us to have some sort of gp2 exercising acctest that would be failing now w/ an iops validation error. We should probably add one if not.

@catsby
Copy link
Contributor Author

catsby commented Dec 4, 2015

Agreed. I'll remove the strict validation. @billputer would iops = 0 be sufficient for "false" for your use case?

@billputer
Copy link

@catsby Yup, that should do the trick.

@catsby
Copy link
Contributor Author

catsby commented Dec 7, 2015

@billputer had to tweak it some, but I think this should work for you. Any chance you can try it out? Otherwise I'll just nag @phinze 😄

@catsby catsby added the waiting-response An issue/pull request is waiting for a response from the community label Dec 7, 2015
@jen20
Copy link
Contributor

jen20 commented Dec 9, 2015

This LGTM (assuming we don't want to wait to fix this with whatever @phinze is cooking up for resource-level validation!)

@catsby
Copy link
Contributor Author

catsby commented Dec 9, 2015

don't know, @phinze: should I delay?

@phinze
Copy link
Contributor

phinze commented Dec 15, 2015

Let's merge this as-is and we can follow up once ResourceValidateFunc finally lands. The conditional read stuff is still going to be valid no matter what we do for validation.

@catsby catsby removed the waiting-response An issue/pull request is waiting for a response from the community label Dec 15, 2015
catsby added a commit that referenced this pull request Dec 15, 2015
providers/aws: Validate IOPs for EBS Volumes
@catsby catsby merged commit 6448242 into master Dec 15, 2015
@catsby catsby deleted the b-aws-ebs-validate branch December 15, 2015 17:33
mengesb added a commit to mengesb/terraform that referenced this pull request Jul 23, 2016
- Already ignoring IOPS on ebs attached non-io1 devices; extended to root_block_device
- Added warning captured from hashicorp#4146 / [../blob/master/builtin/providers/aws/resource_aws_ebs_volume.go#L104](resource_aws_ebs_volume.go#L104)
- Added test when setting IOPS to 330 (11GiB * 30 = 330) on GP2 root device results in AWS reported 100 IOPS (successfully ignored input)
stack72 pushed a commit that referenced this pull request Jul 25, 2016
- Already ignoring IOPS on ebs attached non-io1 devices; extended to root_block_device
- Added warning captured from #4146 / [../blob/master/builtin/providers/aws/resource_aws_ebs_volume.go#L104](resource_aws_ebs_volume.go#L104)
- Added test when setting IOPS to 330 (11GiB * 30 = 330) on GP2 root device results in AWS reported 100 IOPS (successfully ignored input)
@ghost
Copy link

ghost commented Apr 29, 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 Apr 29, 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.

4 participants