-
Notifications
You must be signed in to change notification settings - Fork 762
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Implement config pod status #3544
feat: Implement config pod status #3544
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3544 +/- ##
==========================================
- Coverage 54.49% 48.22% -6.28%
==========================================
Files 134 221 +87
Lines 12329 15371 +3042
==========================================
+ Hits 6719 7413 +694
- Misses 5116 7119 +2003
- Partials 494 839 +345
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
99bfce6
to
d1016c3
Compare
0721779
to
a240878
Compare
|
||
// PodStatusToConfigMapper correlates a ConfigPodStatus with its corresponding Config. | ||
// `selfOnly` tells the mapper to only map statuses corresponding to the current pod. | ||
func PodStatusToConfigMapper(selfOnly bool) handler.TypedMapFunc[*v1beta1.ConfigPodStatus] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like selfOnly
is not being used. This code was copied from expansion templates, which also did not use selfOnly
. This is a bug. Here is an example of proper use of selfOnly
in the constraint controller:
gatekeeper/pkg/controller/constraint/constraint_controller.go
Lines 194 to 198 in 07127f2
err = c.Watch( | |
source.Kind(mgr.GetCache(), &constraintstatusv1beta1.ConstraintPodStatus{}, handler.TypedEnqueueRequestsFromMapFunc(constraintstatus.PodStatusToConstraintMapper(true, util.EventPackerMapFunc())))) | |
if err != nil { | |
return err | |
} |
Here is the basic reasoning:
-
status controllers want to watch all podStatus objects and the primary object because they want to make sure they respond to any changes (i.e. writing status changes, overwriting inappropriate deletes of the status field, etc.)
-
primary controllers want to watch podStatus for the corresponding pod -- if someone deletes a podStatus resource the main object should be re-reconciled to avoid missing state.
As it stands, if a user were to delete the podStatus object, there is a risk that there would be no reconcile.
We should add the appropriate watches to the config and expansion controllers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we have a PR that fixes this in the other controller?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If selfOnly is always required and true, why is this a variable? when does it need to be set to false?
|
||
// Add creates a new config Status Controller and adds it to the Manager. The Manager will set fields on the Controller | ||
// and Start it when the Manager is Started. | ||
func (a *Adder) Add(mgr manager.Manager) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't look like we're gating status controller on whether the status
operation is enabled -- this is bad because it means this controller will not run as a singleton, which invites write conflicts particularly as the # of pods scales.
Example of the status gate:
gatekeeper/pkg/controller/constrainttemplate/constrainttemplate_controller.go
Lines 155 to 178 in 07127f2
if operations.IsAssigned(operations.Status) { | |
// statusEvents will be used to receive events from dynamic watches registered | |
// via the registrar below. | |
statusEvents := make(chan event.GenericEvent, 1024) | |
csAdder := constraintstatus.Adder{ | |
CFClient: cfClient, | |
WatchManager: wm, | |
ControllerSwitch: cs, | |
Events: statusEvents, | |
IfWatching: statusW.IfWatching, | |
} | |
if err := csAdder.Add(mgr); err != nil { | |
return nil, err | |
} | |
ctsAdder := constrainttemplatestatus.Adder{ | |
CfClient: cfClient, | |
WatchManager: wm, | |
ControllerSwitch: cs, | |
} | |
if err := ctsAdder.Add(mgr); err != nil { | |
return nil, err | |
} | |
} |
Though a more appropriate code shape for this PR is probably the mutator status gate:
gatekeeper/pkg/controller/mutatorstatus/mutatorstatus_controller.go
Lines 60 to 62 in 07127f2
if !operations.IsAssigned(operations.MutationStatus) { | |
return nil | |
} |
(however we should depend on Status
, not MutatorStatus
)
We should also fix this for the expansion template status controller (worth verifying it has a similar oversight first).
Long-term a more uniform design pattern for adding status controllers may help avoid similar oversights in the future, but that's beyond the scope of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the logic to use status gate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we create PRs to add it to the other status controllers that do not have a similar gate? This would include expansion template status at the minimum.
d545b1f
to
60ec8d5
Compare
c7e45a5
to
d7d2405
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
almost there! Minor nits and some follow-up items.
|
||
// Add creates a new config Status Controller and adds it to the Manager. The Manager will set fields on the Controller | ||
// and Start it when the Manager is Started. | ||
func (a *Adder) Add(mgr manager.Manager) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we create PRs to add it to the other status controllers that do not have a similar gate? This would include expansion template status at the minimum.
|
||
// PodStatusToConfigMapper correlates a ConfigPodStatus with its corresponding Config. | ||
// `selfOnly` tells the mapper to only map statuses corresponding to the current pod. | ||
func PodStatusToConfigMapper(selfOnly bool) handler.TypedMapFunc[*v1beta1.ConfigPodStatus] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we have a PR that fixes this in the other controller?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code LGTM, pending resolution of either fixing readiness tracker tests in this PR or separating code to separate PR.
dabdc7b
to
eaf85ba
Compare
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
eaf85ba
to
b75a3ea
Compare
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
…ntrollers to use operation.status flag Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM after final minor fix. Good job!
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! changes looks good to me.
One q:
Issue mentiones adding gatekeeper_config
metrics and status tag for the same as well. Do we want to include those changes in this PR or keep the original issue open and follow up with another PR?
Let's make it a separate PR. This one is already sizeable and that's conceptually a different thing. Maybe file a separate issue for metrics and status tag? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
log logr.Logger | ||
} | ||
|
||
// +kubebuilder:rbac:groups=config.gatekeeper.sh,resources=*,verbs=get;list;watch;create;update;patch;delete |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This overrides existing rbac rules per https://github.com/open-policy-agent/gatekeeper/blob/master/pkg/controller/config/config_controller.go#L130-L131
should the old ones be removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think what it does is adds overlapping entries in the role rather than override?
IMO it's safest to just duplicate to avoid accidentally deleting necessary permissions due to code refactors, but not a huge deal either way for me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm ok with keeping it. Just wanted to make sure this is what we want as it trumps the old rules.
groups=config.gatekeeper.sh,resources=*,verbs=get;list;watch;create;update;patch;delete
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, using
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when the PR gets merged):Fixes #2918
Special notes for your reviewer: