use the correct flag name

Author: kannon92

keps/sig-node/5573-cgroup-v1-unsupported/README.md

@@ -91,7 +91,7 @@ By formally moving cgroup v1 to unsupported status, Kubernetes provides a clear
 
 ### Goals
 
-1. **Disable cgroup v1 support by default**: Set the kubelet flag `--disable-cgroupv1-support` to `true` by default, effectively making cgroup v1 unsupported unless explicitly enabled.
+1. **Disable cgroup v1 support by default**: Set the kubelet flag `FailCgroupV1` to `true` by default, effectively making cgroup v1 unsupported unless explicitly enabled.
 
 2. **Clear messaging**: Update warning messages and events to reflect that cgroup v1 is now unsupported rather than in maintenance mode.
 
@@ -119,7 +119,7 @@ The primary risks involve potential disruptions for users who have not yet migra
 
 1. **Existing clusters running cgroup v1**: Users running Kubernetes on hosts with cgroup v1 will need to either:
    - Migrate their hosts to cgroup v2 (recommended)
-   - Explicitly set `--disable-cgroupv1-support=false` to continue using cgroup v1 (not recommended)
+   - Explicitly set `FailCgroupV1=false` to continue using cgroup v1 (not recommended)
 
 2. **Workload compatibility**: Users depending on technologies that require specific versions for cgroup v2 support:
    - OpenJDK / HotSpot: jdk8u372, 11.0.16, 15 and later
@@ -130,7 +130,7 @@ The primary risks involve potential disruptions for users who have not yet migra
 
 **Mitigations**:
 - Provide comprehensive migration documentation and guidance
-- Maintain the ability to override the default behavior with `--disable-cgroupv1-support=false`
+- Change the KubeletConfig field FailCgroupV1 to false.
 - Clear warning messages when cgroup v1 is detected
 - Community support through migration period
 - Advance notice through multiple release cycles
@@ -139,20 +139,20 @@ The primary risks involve potential disruptions for users who have not yet migra
 
 This enhancement primarily involves configuration changes and messaging updates, building on the infrastructure already implemented in KEP-4569.
 
-### Enable fail-cgroup-v1 by default
+### Enable FailCgroupV1 by default
 
-The key technical change is to modify the default value of the kubelet flag `--disable-cgroupv1-support` from `false` to `true`. This change will be implemented in the kubelet configuration types.
+The key technical change is to modify the default value of the kubelet config api `FailCgroupV1` from `false` to `true`. This change will be implemented in the kubelet configuration types.
 
 Current behavior:
 ```go
 // Default: false (cgroup v1 support enabled by default)
-DisableCgroupV1Support: false,
+FailCgroupV1: false,
 ```
 
 Proposed behavior:
 ```go
 // Default: true (cgroup v1 support disabled by default)
-DisableCgroupV1Support: true,
+FailCgroupV1: true,
 ```
 
 ### Update warning messages and events
@@ -204,8 +204,7 @@ implementing this enhancement to ensure the enhancements have also solid foundat
 
 All existing cgroup v2 test jobs must continue to pass. Tests should verify that:
 1. The default behavior correctly disables cgroup v1 support
-2. The override flag `--disable-cgroupv1-support=false` continues to work
-3. Appropriate warning messages are displayed when cgroup v1 is detected
+2. Appropriate warning messages are displayed when cgroup v1 is detected
 
 ##### Unit tests
 
@@ -246,31 +245,16 @@ We expect no non-infra related flakes in the last month as a GA graduation crite
 1. Continue monitoring cgroup v2 CI jobs to ensure stability
 2. Add specific tests for the new default behavior
 3. Ensure all new tests use cgroup v2 hosts
-4. Maintain minimal testing for override scenarios where cgroup v1 is explicitly enabled
+4. Remove all cgroup v1 test lanes.
 
 ### Graduation Criteria
 
-#### Alpha
+#### GA
 
-- Default value for `--disable-cgroupv1-support` changed to `true`
+- Default value for `FailCgroupV1` changed to `true`
 - Updated warning messages and events for unsupported status
 - Documentation updates in kubernetes/enhancements repository
-- Basic test coverage for new default behavior
-
-#### Beta
-
-- Comprehensive testing across multiple scenarios
-- Updated documentation in kubernetes/website
-- Community feedback incorporated
-- Stable behavior across different environments
-
-#### GA
-
-- All tests passing consistently
-- Complete documentation coverage
-- Community migration guidance available
-- Blog post announcing the change
-- Preparation for future removal KEP
+- All e2e testing removed for cgroup v1.
 
 ### Upgrade / Downgrade Strategy
 
@@ -287,7 +271,7 @@ enhancement:
 -->
 
 **Upgrade considerations**:
-- Clusters upgrading to Kubernetes v1.35+ on cgroup v1 hosts will fail to start kubelet unless `--disable-cgroupv1-support=false` is explicitly set
+- Clusters upgrading to Kubernetes v1.35+ on cgroup v1 hosts will fail to start kubelet unless `FailCgroupV1` is set to false
 - Administrators should migrate to cgroup v2 before upgrading or explicitly set the override flag
 - Clear documentation and communication about this breaking change
 
@@ -339,17 +323,17 @@ you need any help or guidance.
 
 ###### How can this feature be enabled / disabled in a live cluster?
 
-This is a default configuration change. The feature can be controlled via the kubelet flag:
-- To disable cgroup v1 support (default): `--disable-cgroupv1-support=true` 
-- To enable cgroup v1 support (override): `--disable-cgroupv1-support=false`
+This is a default configuration change. The feature can be controlled via the kubelet config:
+- To disable cgroup v1 support (default): `FailCgroupV1=true` 
+- To enable cgroup v1 support (override): `FailCgroupV1=false`
 
 ###### Does enabling the feature change any default behavior?
 
 Yes, this change modifies the default behavior. Previously, cgroup v1 support was enabled by default. After this change, cgroup v1 support will be disabled by default.
 
 ###### Can the feature be disabled once it has been enabled (i.e. can we roll back the enablement)?
 
-Yes, users can set `--disable-cgroupv1-support=false` to re-enable cgroup v1 support.
+Yes, users can set `FailCgroupV1=false` to re-enable cgroup v1 support.
 
 ###### What happens if we reenable the feature if it was previously rolled back?
 
@@ -386,7 +370,7 @@ Testing will include:
 
 ###### Is the rollout accompanied by any deprecations and/or removals of features, APIs, fields of API types, flags, etc.?
 
-This change moves cgroup v1 from maintenance mode to unsupported status but does not remove any APIs or flags. The `--disable-cgroupv1-support` flag remains available for override purposes.
+This change moves cgroup v1 from maintenance mode to unsupported status but does not remove any APIs or flags. The `FailCgroupV1` flag remains available for override purposes.
 
 ### Monitoring Requirements
 
@@ -463,7 +447,7 @@ This feature operates at the kubelet level and does not depend on API server or
 
 **Failure mode**: Kubelet fails to start on cgroup v1 hosts
 - **Detection**: Kubelet startup logs and node status
-- **Mitigation**: Set `--disable-cgroupv1-support=false` or migrate to cgroup v2
+- **Mitigation**: Set `FailCgroupV1=false` or migrate to cgroup v2
 - **Diagnostics**: Kubelet logs will clearly indicate cgroup v1 detection and unsupported status
 - **Testing**: Covered in unit and integration tests