1
0
mirror of https://github.com/openshift/installer.git synced 2026-02-05 15:47:14 +01:00

go mod vendor for AWS GP3 changes

This commit is contained in:
John Hixson
2025-11-20 14:25:05 -08:00
committed by Thuan Vo
parent c17a0ff538
commit d05387abb8
9 changed files with 152 additions and 9 deletions

View File

@@ -79,7 +79,6 @@ type CgroupMode string
const (
CgroupModeEmpty CgroupMode = "" // Empty string indicates to honor user set value on the system that should not be overridden by OpenShift
CgroupModeV1 CgroupMode = "v1"
CgroupModeV2 CgroupMode = "v2"
CgroupModeDefault CgroupMode = CgroupModeV2
)

View File

@@ -513,6 +513,14 @@ var (
enableForClusterProfile(SelfManaged, configv1.Default, configv1.DevPreviewNoUpgrade, configv1.TechPreviewNoUpgrade).
mustRegister()
FeatureGateNewOLMBoxCutterRuntime = newFeatureGate("NewOLMBoxCutterRuntime").
reportProblemsToJiraComponent("olm").
contactPerson("pegoncal").
productScope(ocpSpecific).
enhancementPR("https://github.com/openshift/enhancements/pull/1890").
enableForClusterProfile(SelfManaged, configv1.DevPreviewNoUpgrade, configv1.TechPreviewNoUpgrade).
mustRegister()
FeatureGateInsightsOnDemandDataGather = newFeatureGate("InsightsOnDemandDataGather").
reportProblemsToJiraComponent("insights").
contactPerson("tremes").
@@ -799,7 +807,7 @@ var (
enableIn(configv1.DevPreviewNoUpgrade, configv1.TechPreviewNoUpgrade, configv1.Default).
mustRegister()
FeatureGateNoRegistryClusterOperations = newFeatureGate("NoRegistryClusterOperations").
FeatureGateNoRegistryClusterInstall = newFeatureGate("NoRegistryClusterInstall").
reportProblemsToJiraComponent("Installer / Agent based installation").
contactPerson("andfasano").
productScope(ocpSpecific).
@@ -923,4 +931,12 @@ var (
enhancementPR("https://github.com/openshift/enhancements/pull/1803").
enableIn(configv1.DevPreviewNoUpgrade, configv1.TechPreviewNoUpgrade).
mustRegister()
FeatureGateProvisioningRequestAvailable = newFeatureGate("ProvisioningRequestAvailable").
reportProblemsToJiraComponent("Cluster Autoscaler").
contactPerson("elmiko").
productScope(ocpSpecific).
enhancementPR("https://github.com/openshift/enhancements/pull/1752").
enableIn(configv1.DevPreviewNoUpgrade).
mustRegister()
)

View File

@@ -213,6 +213,19 @@ type EBSBlockDeviceSpec struct {
// it is not used in requests to create gp2, st1, sc1, or standard volumes.
// +optional
Iops *int64 `json:"iops,omitempty"`
// throughputMib to provision in MiB/s supported for the volume type. Not applicable to all types.
//
// This parameter is valid only for gp3 volumes.
// Valid Range: Minimum value of 125. Maximum value of 2000.
//
// 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.
//
// +kubebuilder:validation:Minimum:=125
// +kubebuilder:validation:Maximum:=2000
// +optional
ThroughputMib *int32 `json:"throughputMib,omitempty"`
// The size of the volume, in GiB.
//
// Constraints: 1-16384 for General Purpose SSD (gp2), 4-16384 for Provisioned
@@ -225,7 +238,7 @@ type EBSBlockDeviceSpec struct {
// a volume size, the default is the snapshot size.
// +optional
VolumeSize *int64 `json:"volumeSize,omitempty"`
// The volume type: gp2, io1, st1, sc1, or standard.
// volumeType can be of type gp2, gp3, io1, st1, sc1, or standard.
// Default: standard
// +optional
VolumeType *string `json:"volumeType,omitempty"`

View File

@@ -581,6 +581,11 @@ func (in *EBSBlockDeviceSpec) DeepCopyInto(out *EBSBlockDeviceSpec) {
*out = new(int64)
**out = **in
}
if in.ThroughputMib != nil {
in, out := &in.ThroughputMib, &out.ThroughputMib
*out = new(int32)
**out = **in
}
if in.VolumeSize != nil {
in, out := &in.VolumeSize, &out.VolumeSize
*out = new(int64)

View File

@@ -108,8 +108,9 @@ var map_EBSBlockDeviceSpec = map[string]string{
"encrypted": "Indicates whether the EBS volume is encrypted. Encrypted Amazon EBS volumes may only be attached to machines that support Amazon EBS encryption.",
"kmsKey": "Indicates the KMS key that should be used to encrypt the Amazon EBS volume.",
"iops": "The number of I/O operations per second (IOPS) that the volume supports. For io1, this represents the number of IOPS that are provisioned for the volume. For gp2, this represents the baseline performance of the volume and the rate at which the volume accumulates I/O credits for bursting. For more information about General Purpose SSD baseline performance, I/O credits, and bursting, see Amazon EBS Volume Types (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) in the Amazon Elastic Compute Cloud User Guide.\n\nMinimal and maximal IOPS for io1 and gp2 are constrained. Please, check https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html for precise boundaries for individual volumes.\n\nCondition: This parameter is required for requests to create io1 volumes; it is not used in requests to create gp2, st1, sc1, or standard volumes.",
"throughputMib": "throughputMib to provision in MiB/s supported for the volume type. Not applicable to all types.\n\nThis parameter is valid only for gp3 volumes. Valid Range: Minimum value of 125. Maximum value of 2000.\n\nWhen 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.",
"volumeSize": "The size of the volume, in GiB.\n\nConstraints: 1-16384 for General Purpose SSD (gp2), 4-16384 for Provisioned IOPS SSD (io1), 500-16384 for Throughput Optimized HDD (st1), 500-16384 for Cold HDD (sc1), and 1-1024 for Magnetic (standard) volumes. If you specify a snapshot, the volume size must be equal to or larger than the snapshot size.\n\nDefault: If you're creating the volume from a snapshot and don't specify a volume size, the default is the snapshot size.",
"volumeType": "The volume type: gp2, io1, st1, sc1, or standard. Default: standard",
"volumeType": "volumeType can be of type gp2, gp3, io1, st1, sc1, or standard. Default: standard",
}
func (EBSBlockDeviceSpec) SwaggerDoc() map[string]string {

View File

@@ -298,9 +298,9 @@ type IngressControllerSpec struct {
// case HAProxy handles it in the old process and closes
// the connection after sending the response.
//
// - HAProxy's `timeout http-keep-alive` duration expires
// (300 seconds in OpenShift's configuration, not
// configurable).
// - HAProxy's `timeout http-keep-alive` duration expires.
// By default this is 300 seconds, but it can be changed
// using httpKeepAliveTimeout tuning option.
//
// - The client's keep-alive timeout expires, causing the
// client to close the connection.
@@ -344,6 +344,47 @@ type IngressControllerSpec struct {
// +kubebuilder:default:="Immediate"
// +default="Immediate"
IdleConnectionTerminationPolicy IngressControllerConnectionTerminationPolicy `json:"idleConnectionTerminationPolicy,omitempty"`
// closedClientConnectionPolicy controls how the IngressController
// behaves when the client closes the TCP connection while the TLS
// handshake or HTTP request is in progress. This option maps directly
// to HAProxys "abortonclose" option.
//
// Valid values are: "Abort" and "Continue".
// The default value is "Continue".
//
// When set to "Abort", the router will stop processing the TLS handshake
// if it is in progress, and it will not send an HTTP request to the backend server
// if the request has not yet been sent when the client closes the connection.
//
// When set to "Continue", the router will complete the TLS handshake
// if it is in progress, or send an HTTP request to the backend server
// and wait for the backend server's response, regardless of
// whether the client has closed the connection.
//
// Setting "Abort" can help free CPU resources otherwise spent on TLS computation
// for connections the client has already closed, and can reduce request queue
// size, thereby reducing the load on saturated backend servers.
//
// Important Considerations:
//
// - The default policy ("Continue") is HTTP-compliant, and requests
// for aborted client connections will still be served.
// Use the "Continue" policy to allow a client to send a request
// and then immediately close its side of the connection while
// still receiving a response on the half-closed connection.
//
// - When clients use keep-alive connections, the most common case for premature
// closure is when the user wants to cancel the transfer or when a timeout
// occurs. In that case, the "Abort" policy may be used to reduce resource consumption.
//
// - Using RSA keys larger than 2048 bits can significantly slow down
// TLS computations. Consider using the "Abort" policy to reduce CPU usage.
//
// +optional
// +kubebuilder:default:="Continue"
// +default="Continue"
ClosedClientConnectionPolicy IngressControllerClosedClientConnectionPolicy `json:"closedClientConnectionPolicy,omitempty"`
}
// httpCompressionPolicy turns on compression for the specified MIME types.
@@ -1884,6 +1925,36 @@ type IngressControllerTuningOptions struct {
// +optional
ConnectTimeout *metav1.Duration `json:"connectTimeout,omitempty"`
// httpKeepAliveTimeout defines the maximum allowed time to wait for
// a new HTTP request to appear on a connection from the client to the router.
//
// This field expects an unsigned duration string of a decimal number, with optional
// fraction and a unit suffix, e.g. "300ms", "1.5s" or "2m45s".
// Valid time units are "ms", "s", "m".
// The allowed range is from 1 millisecond to 15 minutes.
//
// When omitted, this means the user has no opinion and the platform is left
// to choose a reasonable default. This default is subject to change over time.
// The current default is 300s.
//
// Low values (tens of milliseconds or less) can cause clients to close and reopen connections
// for each request, leading to reduced connection sharing.
// For HTTP/2, special care should be taken with low values.
// A few seconds is a reasonable starting point to avoid holding idle connections open
// while still allowing subsequent requests to reuse the connection.
//
// High values (minutes or more) favor connection reuse but may cause idle
// connections to linger longer.
//
// +kubebuilder:validation:Type:=string
// +kubebuilder:validation:XValidation:rule="self.matches('^([0-9]+(\\\\.[0-9]+)?(ms|s|m))+$')",message="httpKeepAliveTimeout must be a valid duration string composed of an unsigned integer value, optionally followed by a decimal fraction and a unit suffix (ms, s, m)"
// +kubebuilder:validation:XValidation:rule="!self.matches('^([0-9]+(\\\\.[0-9]+)?(ms|s|m))+$') || duration(self) <= duration('15m')",message="httpKeepAliveTimeout must be less than or equal to 15 minutes"
// +kubebuilder:validation:XValidation:rule="!self.matches('^([0-9]+(\\\\.[0-9]+)?(ms|s|m))+$') || duration(self) >= duration('1ms')",message="httpKeepAliveTimeout must be greater than or equal to 1 millisecond"
// +kubebuilder:validation:MinLength=1
// +kubebuilder:validation:MaxLength=16
// +optional
HTTPKeepAliveTimeout *metav1.Duration `json:"httpKeepAliveTimeout,omitempty"`
// tlsInspectDelay defines how long the router can hold data to find a
// matching route.
//
@@ -2140,3 +2211,34 @@ const (
// connection.
IngressControllerConnectionTerminationPolicyDeferred IngressControllerConnectionTerminationPolicy = "Deferred"
)
// IngressControllerClosedClientConnectionPolicy controls how the IngressController
// behaves when the client closes the TCP connection while the TLS
// handshake or HTTP request is in progress.
//
// +kubebuilder:validation:Enum=Abort;Continue
type IngressControllerClosedClientConnectionPolicy string
const (
// IngressControllerClosedClientConnectionPolicyAbort aborts processing early when the client
// closes the connection.
//
// This affects two types of processing: TLS handshake computation on the router
// and request handling.
//
// When the client closes the connection, the router will stop processing
// the TLS handshake, preventing unnecessary CPU work.
//
// If the HTTP request has not yet been sent to the backend, it will be aborted.
// If the request is already being processed by the backend, the router will
// half-close the connection to signal this condition to the backend server,
// which can then decide how to proceed.
IngressControllerClosedClientConnectionPolicyAbort IngressControllerClosedClientConnectionPolicy = "Abort"
// IngressControllerClosedClientConnectionPolicyContinue continues processing even if the client
// closes the connection.
//
// The router will complete the TLS handshake and wait for the backend
// server's response regardless of the client having closed the connection.
IngressControllerClosedClientConnectionPolicyContinue IngressControllerClosedClientConnectionPolicy = "Continue"
)

View File

@@ -2564,6 +2564,11 @@ func (in *IngressControllerTuningOptions) DeepCopyInto(out *IngressControllerTun
*out = new(metav1.Duration)
**out = **in
}
if in.HTTPKeepAliveTimeout != nil {
in, out := &in.HTTPKeepAliveTimeout, &out.HTTPKeepAliveTimeout
*out = new(metav1.Duration)
**out = **in
}
if in.TLSInspectDelay != nil {
in, out := &in.TLSInspectDelay, &out.TLSInspectDelay
*out = new(metav1.Duration)

View File

@@ -1080,7 +1080,8 @@ var map_IngressControllerSpec = map[string]string{
"tuningOptions": "tuningOptions defines parameters for adjusting the performance of ingress controller pods. All fields are optional and will use their respective defaults if not set. See specific tuningOptions fields for more details.\n\nSetting fields within tuningOptions is generally not recommended. The default values are suitable for most configurations.",
"unsupportedConfigOverrides": "unsupportedConfigOverrides allows specifying unsupported configuration options. Its use is unsupported.",
"httpCompression": "httpCompression defines a policy for HTTP traffic compression. By default, there is no HTTP compression.",
"idleConnectionTerminationPolicy": "idleConnectionTerminationPolicy maps directly to HAProxy's idle-close-on-response option and controls whether HAProxy keeps idle frontend connections open during a soft stop (router reload).\n\nAllowed values for this field are \"Immediate\" and \"Deferred\". The default value is \"Immediate\".\n\nWhen set to \"Immediate\", idle connections are closed immediately during router reloads. This ensures immediate propagation of route changes but may impact clients sensitive to connection resets.\n\nWhen set to \"Deferred\", HAProxy will maintain idle connections during a soft reload instead of closing them immediately. These connections remain open until any of the following occurs:\n\n - A new request is received on the connection, in which\n case HAProxy handles it in the old process and closes\n the connection after sending the response.\n\n - HAProxy's `timeout http-keep-alive` duration expires\n (300 seconds in OpenShift's configuration, not\n configurable).\n\n - The client's keep-alive timeout expires, causing the\n client to close the connection.\n\nSetting Deferred can help prevent errors in clients or load balancers that do not properly handle connection resets. Additionally, this option allows you to retain the pre-2.4 HAProxy behaviour: in HAProxy version 2.2 (OpenShift versions < 4.14), maintaining idle connections during a soft reload was the default behaviour, but starting with HAProxy 2.4, the default changed to closing idle connections immediately.\n\nImportant Consideration:\n\n - Using Deferred will result in temporary inconsistencies\n for the first request on each persistent connection\n after a route update and router reload. This request\n will be processed by the old HAProxy process using its\n old configuration. Subsequent requests will use the\n updated configuration.\n\nOperational Considerations:\n\n - Keeping idle connections open during reloads may lead\n to an accumulation of old HAProxy processes if\n connections remain idle for extended periods,\n especially in environments where frequent reloads\n occur.\n\n - Consider monitoring the number of HAProxy processes in\n the router pods when Deferred is set.\n\n - You may need to enable or adjust the\n `ingress.operator.openshift.io/hard-stop-after`\n duration (configured via an annotation on the\n IngressController resource) in environments with\n frequent reloads to prevent resource exhaustion.",
"idleConnectionTerminationPolicy": "idleConnectionTerminationPolicy maps directly to HAProxy's idle-close-on-response option and controls whether HAProxy keeps idle frontend connections open during a soft stop (router reload).\n\nAllowed values for this field are \"Immediate\" and \"Deferred\". The default value is \"Immediate\".\n\nWhen set to \"Immediate\", idle connections are closed immediately during router reloads. This ensures immediate propagation of route changes but may impact clients sensitive to connection resets.\n\nWhen set to \"Deferred\", HAProxy will maintain idle connections during a soft reload instead of closing them immediately. These connections remain open until any of the following occurs:\n\n - A new request is received on the connection, in which\n case HAProxy handles it in the old process and closes\n the connection after sending the response.\n\n - HAProxy's `timeout http-keep-alive` duration expires.\n By default this is 300 seconds, but it can be changed\n using httpKeepAliveTimeout tuning option.\n\n - The client's keep-alive timeout expires, causing the\n client to close the connection.\n\nSetting Deferred can help prevent errors in clients or load balancers that do not properly handle connection resets. Additionally, this option allows you to retain the pre-2.4 HAProxy behaviour: in HAProxy version 2.2 (OpenShift versions < 4.14), maintaining idle connections during a soft reload was the default behaviour, but starting with HAProxy 2.4, the default changed to closing idle connections immediately.\n\nImportant Consideration:\n\n - Using Deferred will result in temporary inconsistencies\n for the first request on each persistent connection\n after a route update and router reload. This request\n will be processed by the old HAProxy process using its\n old configuration. Subsequent requests will use the\n updated configuration.\n\nOperational Considerations:\n\n - Keeping idle connections open during reloads may lead\n to an accumulation of old HAProxy processes if\n connections remain idle for extended periods,\n especially in environments where frequent reloads\n occur.\n\n - Consider monitoring the number of HAProxy processes in\n the router pods when Deferred is set.\n\n - You may need to enable or adjust the\n `ingress.operator.openshift.io/hard-stop-after`\n duration (configured via an annotation on the\n IngressController resource) in environments with\n frequent reloads to prevent resource exhaustion.",
"closedClientConnectionPolicy": "closedClientConnectionPolicy controls how the IngressController behaves when the client closes the TCP connection while the TLS handshake or HTTP request is in progress. This option maps directly to HAProxys \"abortonclose\" option.\n\nValid values are: \"Abort\" and \"Continue\". The default value is \"Continue\".\n\nWhen set to \"Abort\", the router will stop processing the TLS handshake if it is in progress, and it will not send an HTTP request to the backend server if the request has not yet been sent when the client closes the connection.\n\nWhen set to \"Continue\", the router will complete the TLS handshake if it is in progress, or send an HTTP request to the backend server and wait for the backend server's response, regardless of whether the client has closed the connection.\n\nSetting \"Abort\" can help free CPU resources otherwise spent on TLS computation for connections the client has already closed, and can reduce request queue size, thereby reducing the load on saturated backend servers.\n\nImportant Considerations:\n\n - The default policy (\"Continue\") is HTTP-compliant, and requests\n for aborted client connections will still be served.\n Use the \"Continue\" policy to allow a client to send a request\n and then immediately close its side of the connection while\n still receiving a response on the half-closed connection.\n\n - When clients use keep-alive connections, the most common case for premature\n closure is when the user wants to cancel the transfer or when a timeout\n occurs. In that case, the \"Abort\" policy may be used to reduce resource consumption.\n\n - Using RSA keys larger than 2048 bits can significantly slow down\n TLS computations. Consider using the \"Abort\" policy to reduce CPU usage.",
}
func (IngressControllerSpec) SwaggerDoc() map[string]string {
@@ -1115,6 +1116,7 @@ var map_IngressControllerTuningOptions = map[string]string{
"serverFinTimeout": "serverFinTimeout defines how long a connection will be held open while waiting for the server/backend response to the client closing the connection.\n\nIf unset, the default timeout is 1s",
"tunnelTimeout": "tunnelTimeout defines how long a tunnel connection (including websockets) will be held open while the tunnel is idle.\n\nIf unset, the default timeout is 1h",
"connectTimeout": "connectTimeout defines the maximum time to wait for a connection attempt to a server/backend to succeed.\n\nThis field expects an unsigned duration string of decimal numbers, each with optional fraction and a unit suffix, e.g. \"300ms\", \"1.5h\" or \"2h45m\". Valid time units are \"ns\", \"us\" (or \"µs\" U+00B5 or \"μs\" U+03BC), \"ms\", \"s\", \"m\", \"h\".\n\nWhen omitted, this means the user has no opinion and the platform is left to choose a reasonable default. This default is subject to change over time. The current default is 5s.",
"httpKeepAliveTimeout": "httpKeepAliveTimeout defines the maximum allowed time to wait for a new HTTP request to appear on a connection from the client to the router.\n\nThis field expects an unsigned duration string of a decimal number, with optional fraction and a unit suffix, e.g. \"300ms\", \"1.5s\" or \"2m45s\". Valid time units are \"ms\", \"s\", \"m\". The allowed range is from 1 millisecond to 15 minutes.\n\nWhen omitted, this means the user has no opinion and the platform is left to choose a reasonable default. This default is subject to change over time. The current default is 300s.\n\nLow values (tens of milliseconds or less) can cause clients to close and reopen connections for each request, leading to reduced connection sharing. For HTTP/2, special care should be taken with low values. A few seconds is a reasonable starting point to avoid holding idle connections open while still allowing subsequent requests to reuse the connection.\n\nHigh values (minutes or more) favor connection reuse but may cause idle connections to linger longer.",
"tlsInspectDelay": "tlsInspectDelay defines how long the router can hold data to find a matching route.\n\nSetting this too short can cause the router to fall back to the default certificate for edge-terminated or reencrypt routes even when a better matching certificate could be used.\n\nIf unset, the default inspect delay is 5s",
"healthCheckInterval": "healthCheckInterval defines how long the router waits between two consecutive health checks on its configured backends. This value is applied globally as a default for all routes, but may be overridden per-route by the route annotation \"router.openshift.io/haproxy.health.check.interval\".\n\nExpects an unsigned duration string of decimal numbers, each with optional fraction and a unit suffix, eg \"300ms\", \"1.5h\" or \"2h45m\". Valid time units are \"ns\", \"us\" (or \"µs\" U+00B5 or \"μs\" U+03BC), \"ms\", \"s\", \"m\", \"h\".\n\nSetting this to less than 5s can cause excess traffic due to too frequent TCP health checks and accompanying SYN packet storms. Alternatively, setting this too high can result in increased latency, due to backend servers that are no longer available, but haven't yet been detected as such.\n\nAn empty or zero healthCheckInterval means no opinion and IngressController chooses a default, which is subject to change over time. Currently the default healthCheckInterval value is 5s.\n\nCurrently the minimum allowed value is 1s and the maximum allowed value is 2147483647ms (24.85 days). Both are subject to change over time.",
"maxConnections": "maxConnections defines the maximum number of simultaneous connections that can be established per HAProxy process. Increasing this value allows each ingress controller pod to handle more connections but at the cost of additional system resources being consumed.\n\nPermitted values are: empty, 0, -1, and the range 2000-2000000.\n\nIf this field is empty or 0, the IngressController will use the default value of 50000, but the default is subject to change in future releases.\n\nIf the value is -1 then HAProxy will dynamically compute a maximum value based on the available ulimits in the running container. Selecting -1 (i.e., auto) will result in a large value being computed (~520000 on OpenShift >=4.10 clusters) and therefore each HAProxy process will incur significant memory usage compared to the current default of 50000.\n\nSetting a value that is greater than the current operating system limit will prevent the HAProxy process from starting.\n\nIf you choose a discrete value (e.g., 750000) and the router pod is migrated to a new node, there's no guarantee that that new node has identical ulimits configured. In such a scenario the pod would fail to start. If you have nodes with different ulimits configured (e.g., different tuned profiles) and you choose a discrete value then the guidance is to use -1 and let the value be computed dynamically at runtime.\n\nYou can monitor memory usage for router containers with the following metric: 'container_memory_working_set_bytes{container=\"router\",namespace=\"openshift-ingress\"}'.\n\nYou can monitor memory usage of individual HAProxy processes in router containers with the following metric: 'container_memory_working_set_bytes{container=\"router\",namespace=\"openshift-ingress\"}/container_processes{container=\"router\",namespace=\"openshift-ingress\"}'.",

2
vendor/modules.txt vendored
View File

@@ -1354,7 +1354,7 @@ github.com/opencontainers/image-spec/specs-go/v1
# github.com/opencontainers/runtime-spec v1.2.0
## explicit
github.com/opencontainers/runtime-spec/specs-go
# github.com/openshift/api v0.0.0-20251117165054-348370f055bf
# github.com/openshift/api v0.0.0-20251120220512-cb382c9eaf42
## explicit; go 1.24.0
github.com/openshift/api/annotations
github.com/openshift/api/config/v1