CORS-4212: AWS: Add the ability to configure throughput on GP3 volumes #2480

jhixson74 · 2025-09-17T05:07:05Z

GP3 volumes have the ability to configure throughput from 125 MiB/s to 1000 MiB/s. This allows the ability to set this at install time in the install-config.

https://issues.redhat.com/browse/CORS-4212

openshift-ci-robot · 2025-09-17T05:07:09Z

@jhixson74: This pull request references CORS-4212 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.21.0" version, but no target version was set.

In response to this:

GP3 volumes have the ability to configure throughput from 125 MiB/s to 1000 MiB/s. This allows the ability to set this at install time in the install-config.

https://issues.redhat.com/browse/CORS-4212

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

openshift-ci · 2025-09-17T05:07:15Z

Hello @jhixson74! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

openshift-ci · 2025-09-17T05:08:16Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign deads2k for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

jhixson74 · 2025-09-17T05:48:09Z

I see that the linter is failing. For the life of me, I don't know why since every other field in that struct also does not start with the name. Any pointers? ;-)

JoelSpeed · 2025-09-17T10:37:14Z

Pre-existing fields do not meet conventions, please follow the linter so that new content does meet conventions.
All new fields should have godoc starting with the serialised version of the field name. throughput is...

JoelSpeed · 2025-09-17T10:39:18Z

machine/v1beta1/types_awsprovider.go

+	//
+	// Valid Range: Minimum value of 125. Maximum value of 1000.
+	// +optional
+	Throughput *int64 `json:"throughput,omitempty"`


Do we really need an int64 if the maximum value is 1000?

I would say no, we don't, and agree with you. However, this is what the AWS sdk uses so I went with that:

(can't display the file due to how large it is but you want to view the CreateVolumeInput struct)

https://raw.githubusercontent.com/aws/aws-sdk-go/refs/heads/main/service/ec2/api.go

Thoughts? I'm happy to change it.

Prefer to align to downstream API conventions rather then upstream APIs, so would switch to int32 here

@JoelSpeed CAPA uses int64 as well. Do you still want to make it an int32?

https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/88cb4b92b1a76591623e9d5ef347bfdc22010622/api/v1beta2/types.go#L441

Sigh. An int32 is the right thing to use, but I'm ok if we keep as int64 given CAPA has made that decision. Given this is not a structured API, it makes little difference anyway (where in a structured API it does change the schema)

Just wanted to add that CAPA, even though using int64 for the ebs throughput field, it actually converts the value to int32. This is the result of migrating to AWS SDK v2, which uses the int32 now.

https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/88cb4b92b1a76591623e9d5ef347bfdc22010622/pkg/cloud/services/ec2/instances.go#L728-L736

So, I agree int32 is best :D

JoelSpeed · 2025-09-17T11:52:10Z

Is this feature available in CAPA upstream?

jhixson74 · 2025-09-17T15:37:20Z

Is this feature available in CAPA upstream?

Yes.

tthvo · 2025-09-17T19:28:20Z

machine/v1beta1/types_awsprovider.go

 	// 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 supported for the volume type. Not applicable to all types.


Suggested change

// throughput to provision in MiB/s supported for the volume type. Not applicable to all types.

// Throughput to provision in MiB/s supported for the volume type. Not applicable to all types.

Not sure if lint happy with this 🤔?

Locally, make lint is expecting the lowercase version. Uppercase fails. It passed the lint test, so I'm inclined to believe the lowercase version is the expectation here.

Ahh thanks, that's a bit odd tho :D

Oh, I missed Joel's comment: #2480 (comment). That makes sense now. Sorry :D

tthvo · 2025-09-17T19:33:42Z

machine/v1beta1/types_awsprovider.go

+	//
+	// Valid Range: Minimum value of 125. Maximum value of 1000.
+	// +optional
+	Throughput *int32 `json:"throughput,omitempty"`


Just wondering if we need to mention the default here? That should be 125 MiB/s right?

This parameter, just like Iops above it, will set the default when not configured.

Also, it is only valid for gp3 volumes. I don't know what behavior would occur if we set it to 125 on a non-gp3 volume. 0 is a good default.

Right, I was thinking of mentioning in the description about what the default value will be set if not configured.

But i guess if Iops is not saying anything, we can skip it :D

@jhixson74 Though, one more question: I see the we define the valid range

Valid Range: Minimum value of 125. Maximum value of 1000.

Do we expect this change in the future (i.e. AWS might announce new limits)? If so, should we follow the field Iops and say this instead:

// Minimal and maximal throughput for gp3 are constrained. Please, check // https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html // for precise boundaries for individual volumes.

We tend to include this kind of information, in a sentence approximately

When omitted, this means no opinion, and the platform is left to choose a reasonable default, which is subject to change over time. The current default is 125.

tthvo · 2025-09-17T21:22:02Z

IIUC, the throughput setting is not yet supported in MAPI (thus this PR is created) right?

From OCPSTRAT-2410, it looks like we are not looking to add support MAPI, but rather wait for CAPI migration in OCPSTRAT-1992 (the throughput is already supported there). So, is this change still needed?

I might be misunderstanding something...

JoelSpeed · 2025-09-18T13:49:27Z

machine/v1beta1/types_awsprovider.go

+	//
+	// Valid Range: Minimum value of 125. Maximum value of 1000.
+	// +optional
+	Throughput *int32 `json:"throughput,omitempty"`


We tend to include this kind of information, in a sentence approximately

When omitted, this means no opinion, and the platform is left to choose a reasonable default, which is subject to change over time. The current default is 125.

JoelSpeed · 2025-09-18T13:50:11Z

machine/v1beta1/types_awsprovider.go

+	//
+	// Valid Range: Minimum value of 125. Maximum value of 1000.
+	// +optional
+	Throughput *int32 `json:"throughput,omitempty"`


We should probably call this field ThroughputMiB, we prefer putting units on integer field names when there is a unit implicitly

@JoelSpeed I followed the conventions of what the current struct looks like. None of the fields contain units of measurement in the name. IMO this would look a little strange with the rest of the fields not containing the same.

So, for clarity and to get this PR further along:

Update comment

Update to be int32

Add unit of measurement to filed name?

We made a choice that new fields would follow newer conventions, and that we wouldn't repeat mistakes of the past, so I think in this case, we should still change the name yes, ThroughputMiB, and update the docs as with the other suggestion.

Validation on this API is implemented in a webhook, not openapi, so I think this has to stay as a pointer so that we can ensure in the webhook that it is not accidentally set to 0 by an unstructured client

GP3 volumes have the ability to configure throughput from 125 MiB/s to 1000 MiB/s. This allows the ability to set this at install time in the install-config. https://issues.redhat.com/browse/CORS-4212

openshift-ci · 2025-09-19T23:25:29Z

@jhixson74: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

patrickdillon · 2025-09-22T19:21:34Z

+1 to @tthvo's #2480 (comment)

I'm confused. IIUC this PR is adding configuration for MAPI; but MAPI-support is not part of the plan, this is a CAPI-only feature. I think we should just depend on the existing CAPI API and close this PR. @jhixson74 @JoelSpeed can you please clarify?

openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Sep 17, 2025

openshift-ci bot added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label Sep 17, 2025

jhixson74 mentioned this pull request Sep 17, 2025

CORS-4212: AWS: Add the ability to configure throughput on GP3 volumes openshift/installer#9945

Open

openshift-ci bot requested review from everettraven and JoelSpeed September 17, 2025 05:08

JoelSpeed reviewed Sep 17, 2025

View reviewed changes

jhixson74 force-pushed the master_aws_gp3_throughput branch from 4a4d3cf to ee12153 Compare September 17, 2025 17:36

tthvo reviewed Sep 17, 2025

View reviewed changes

JoelSpeed reviewed Sep 18, 2025

View reviewed changes

jhixson74 force-pushed the master_aws_gp3_throughput branch from ee12153 to ab99e54 Compare September 19, 2025 22:21

AWS: Add the ability to configure throughput on GP3 volumes

b7238bc

GP3 volumes have the ability to configure throughput from 125 MiB/s to 1000 MiB/s. This allows the ability to set this at install time in the install-config. https://issues.redhat.com/browse/CORS-4212

jhixson74 force-pushed the master_aws_gp3_throughput branch from ab99e54 to b7238bc Compare September 19, 2025 22:49

	// throughput to provision in MiB/s supported for the volume type. Not applicable to all types.
	// Throughput to provision in MiB/s supported for the volume type. Not applicable to all types.

CORS-4212: AWS: Add the ability to configure throughput on GP3 volumes #2480

Are you sure you want to change the base?

CORS-4212: AWS: Add the ability to configure throughput on GP3 volumes #2480

Uh oh!

Conversation

jhixson74 commented Sep 17, 2025

Uh oh!

openshift-ci-robot commented Sep 17, 2025 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci bot commented Sep 17, 2025

Uh oh!

openshift-ci bot commented Sep 17, 2025

Uh oh!

jhixson74 commented Sep 17, 2025

Uh oh!

JoelSpeed commented Sep 17, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JoelSpeed commented Sep 17, 2025

Uh oh!

jhixson74 commented Sep 17, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tthvo commented Sep 17, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

openshift-ci bot commented Sep 19, 2025

Uh oh!

patrickdillon commented Sep 22, 2025

Uh oh!

Uh oh!

openshift-ci-robot commented Sep 17, 2025 •

edited by openshift-ci bot

Loading