Skip to content

Conversation

jhixson74
Copy link
Member

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 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-robot
Copy link

openshift-ci-robot commented Sep 17, 2025

@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.

Copy link
Contributor

openshift-ci bot commented Sep 17, 2025

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 openshift-ci bot added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label Sep 17, 2025
Copy link
Contributor

openshift-ci bot commented Sep 17, 2025

[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:

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

@jhixson74
Copy link
Member Author

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
Copy link
Contributor

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...

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

Choose a reason for hiding this comment

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

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

Copy link
Member Author

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

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

Copy link
Member Author

Choose a reason for hiding this comment

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

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

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

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)

Copy link
Member

Choose a reason for hiding this comment

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

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
Copy link
Contributor

Is this feature available in CAPA upstream?

@jhixson74
Copy link
Member Author

Is this feature available in CAPA upstream?

Yes.

@jhixson74 jhixson74 force-pushed the master_aws_gp3_throughput branch from 4a4d3cf to ee12153 Compare September 17, 2025 17:36
// 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.
Copy link
Member

Choose a reason for hiding this comment

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

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 🤔?

Copy link
Member Author

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Member

Choose a reason for hiding this comment

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

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

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

Choose a reason for hiding this comment

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

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

Copy link
Member Author

Choose a reason for hiding this comment

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

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

Copy link
Member Author

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Member

Choose a reason for hiding this comment

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

@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.

Copy link
Contributor

Choose a reason for hiding this comment

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

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
Copy link
Member

tthvo commented Sep 17, 2025

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...

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

Choose a reason for hiding this comment

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

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.

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

Choose a reason for hiding this comment

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

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

Copy link
Member Author

Choose a reason for hiding this comment

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

@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?

Copy link
Contributor

Choose a reason for hiding this comment

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

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

@jhixson74 jhixson74 force-pushed the master_aws_gp3_throughput branch from ee12153 to ab99e54 Compare September 19, 2025 22:21
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 jhixson74 force-pushed the master_aws_gp3_throughput branch from ab99e54 to b7238bc Compare September 19, 2025 22:49
Copy link
Contributor

openshift-ci bot commented Sep 19, 2025

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants