Skip to content

Commit b598ea5

Browse files
committed
add PRR approval request file and filled out PRR questionnaire just for alpha relevant sections.
1 parent ba195b6 commit b598ea5

File tree

2 files changed

+28
-3
lines changed

2 files changed

+28
-3
lines changed
Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
# The KEP must have an approver from the
2+
# "prod-readiness-approvers" group
3+
# of http://git.k8s.io/enhancements/OWNERS_ALIASES
4+
kep-number: 3619
5+
alpha:
6+
approver: "@johnbelamaric"

keps/sig-node/3619-supplemental-groups-policy/README.md

Lines changed: 22 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -671,9 +671,9 @@ well as the [existing list] of feature gates.
671671
[existing list]: https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/
672672
-->
673673

674-
- [ ] Feature gate (also fill in values in `kep.yaml`)
675-
- Feature gate name:
676-
- Components depending on the feature gate:
674+
- [x] Feature gate (also fill in values in `kep.yaml`)
675+
- Feature gate name: SupplementalGroupsPolicy
676+
- Components depending on the feature gate: kube-apiserver, kubelet, (and CRI implementations(e.g. containerd, cri-o))
677677
- [ ] Other
678678
- Describe the mechanism:
679679
- Will enabling / disabling the feature require downtime of the control
@@ -687,6 +687,7 @@ well as the [existing list] of feature gates.
687687
Any change of default behavior may be surprising to users or break existing
688688
automations, so be extremely careful here.
689689
-->
690+
No. Just introducing new API fields in Pod spec and CRI which does NOT change the default behavior.
690691

691692
###### Can the feature be disabled once it has been enabled (i.e. can we roll back the enablement)?
692693

@@ -701,8 +702,12 @@ feature.
701702
NOTE: Also set `disable-supported` to `true` or `false` in `kep.yaml`.
702703
-->
703704

705+
Yes. It can be disabled after enabled. However, users should pay attention that gids of container processes in pods with `IgnoreGroupsInImage` policy would change. It means the action might break the application in permission. We plan to provide a way for users to detect which pods are affected.
706+
704707
###### What happens if we reenable the feature if it was previously rolled back?
705708

709+
Just the policy `IgnoreGroupsInImage` is reenabled. Users should pay attention that gids of containers in pods with `IgnoreGroupsInImage` policy would change. It means that the action might break the application in permission. We plan to provide a way for users to detect which pods are affected.
710+
706711
###### Are there any tests for feature enablement/disablement?
707712

708713
<!--
@@ -718,6 +723,8 @@ You can take a look at one potential example of such test in:
718723
https://github.com/kubernetes/kubernetes/pull/97058/files#diff-7826f7adbc1996a05ab52e3f5f02429e94b68ce6bce0dc534d1be636154fded3R246-R282
719724
-->
720725

726+
Planned for Alpha.
727+
721728
### Rollout, Upgrade and Rollback Planning
722729

723730
<!--
@@ -880,6 +887,8 @@ Focusing mostly on:
880887
heartbeats, leader election, etc.)
881888
-->
882889

890+
No. Just introducing new API fields in Pod spec and CRI which does NOT change the default behavior.
891+
883892
###### Will enabling / using this feature result in introducing new API types?
884893

885894
<!--
@@ -889,6 +898,8 @@ Describe them, providing:
889898
- Supported number of objects per namespace (for namespace-scoped objects)
890899
-->
891900

901+
No.
902+
892903
###### Will enabling / using this feature result in any new calls to the cloud provider?
893904

894905
<!--
@@ -897,6 +908,8 @@ Describe them, providing:
897908
- Estimated increase:
898909
-->
899910

911+
No.
912+
900913
###### Will enabling / using this feature result in increasing size or count of the existing API objects?
901914

902915
<!--
@@ -906,6 +919,8 @@ Describe them, providing:
906919
- Estimated amount of new objects: (e.g., new Object X for every existing Pod)
907920
-->
908921

922+
No.
923+
909924
###### Will enabling / using this feature result in increasing time taken by any operations covered by existing SLIs/SLOs?
910925

911926
<!--
@@ -917,6 +932,8 @@ Think about adding additional work or introducing new steps in between
917932
[existing SLIs/SLOs]: https://git.k8s.io/community/sig-scalability/slos/slos.md#kubernetes-slisslos
918933
-->
919934

935+
No.
936+
920937
###### Will enabling / using this feature result in non-negligible increase of resource usage (CPU, RAM, disk, IO, ...) in any components?
921938

922939
<!--
@@ -929,6 +946,8 @@ This through this both in small and large cases, again with respect to the
929946
[supported limits]: https://git.k8s.io/community//sig-scalability/configs-and-limits/thresholds.md
930947
-->
931948

949+
No.
950+
932951
### Troubleshooting
933952

934953
<!--

0 commit comments

Comments
 (0)