-
Notifications
You must be signed in to change notification settings - Fork 608
WIP: add throughput field to EBSBlockDevice in machine-api #2220
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -165,6 +165,11 @@ type EBSBlockDeviceSpec struct { | |
| // it is not used in requests to create gp2, st1, sc1, or standard volumes. | ||
| // +optional | ||
| Iops *int64 `json:"iops,omitempty"` | ||
| // Throughput to provision in MiB/s. This parameter is valid only for gp3 volumes. | ||
| // | ||
| // Constraints: 125-1000 for General Purpose SSD (gp3) | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. can we validate this constraints with min/max and that this is only set when VolumeType=gp3 with CEL
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. can we also doc what's default if unset and since this is mutable what happens if changed day2? |
||
| // +optional | ||
| Throughput *int64 `json:"throughput,omitempty"` | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm still learning the ropes for what guidelines we typically follow for the openshift APIs when reviewing the machine APIs as they don't result in CRDs. I'm going to review this change from a standard openshift API change perspective and may make some slight tweaks based on what I do know about how the machine types are used.
// throughput is an optional field used to specify the throughput, in MiB/s, that the volume should be provisioned with.
// throughput may be specified when volumeType is set to gp3 and is forbidden otherwise.
// throughput must be greater than or equal to 125 and less than or equal to 1000.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also worth noting that this doesn't need to be a pointer if it's omitempty, a Go marshalled zero value won't show up so it won't trigger the validation on size limits |
||
| // The size of the volume, in GiB. | ||
| // | ||
| // Constraints: 1-16384 for General Purpose SSD (gp2), 4-16384 for Provisioned | ||
|
|
||
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CAPI docs:
Do we want to echo that punt to AWS? Or do we want the inlined AWS context you have here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was following this, which I felt was more informative.
https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_EbsBlockDevice.html
"This only applies to the enumerated volume types" is more helpful than "This doesn't apply to some unenumerated volumes types"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is more helpful while it's accurate, but it means you're on the hook to keep it accurate. The rate of AWS-side changes is likely not high, so it could go either way. I'm just pointing out that CAPI has gone the punt-to-AWS way.