feat: Implement config pod status

[abhipatnala]

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:

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 49.54545% with 111 lines in your changes missing coverage. Please review.

Project coverage is 48.15%. Comparing base (3350319) to head (7bf092d).
Report is 150 commits behind head on master.

Files with missing lines	Patch %	Lines
apis/status/v1beta1/zz_generated.deepcopy.go	0.00%	62 Missing ⚠️
...controller/configstatus/configstatus_controller.go	67.12%	15 Missing and 9 partials ⚠️
pkg/controller/config/config_controller.go	63.15%	13 Missing and 8 partials ⚠️
apis/status/v1beta1/configpodstatus_types.go	80.00%	2 Missing and 2 partials ⚠️

❗ There is a different number of reports uploaded between BASE (3350319) and HEAD (7bf092d). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (3350319)	HEAD (7bf092d)
unittests	2	1

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3544      +/-   ##
==========================================
- Coverage   54.49%   48.15%   -6.35%     
==========================================
  Files         134      221      +87     
  Lines       12329    15348    +3019     
==========================================
+ Hits         6719     7391     +672     
- Misses       5116     7121    +2005     
- Partials      494      836     +342     

Flag	Coverage Δ
unittests	48.15% <49.54%> (-6.35%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[maxsmythe]

Probably don't want this in the API docs...

[abhipatnala]

updated.

[maxsmythe]

This is pure test code, it should live in the test file.

[abhipatnala]

Updated. moved code to test file

[maxsmythe]

comment is redundant as-worded. Potentially could be adding extra context, or could be citing the code as-written.

"K8s API conventions consider an object to be deleted when either the object no longer exists or when a deletion timestamp has been set"

would be a more useful comment -- it highlights that the reason this line of code exists is to align with an API convention.

[abhipatnala]

Updated the comment.

[maxsmythe]

Should "config-controller: error establishing watches for new syncOnly:" be written to the status object? Maybe with a more user-friendly error string?

[maxsmythe]

stale comment, also comment is not helpful, as it describes obvious code function

[abhipatnala]

Deleted stale comment.

[maxsmythe]

unhelpful comment

[abhipatnala]

Updated with more useful comment

[maxsmythe]

stale comment

[abhipatnala]

Deleted

[maxsmythe]

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.

[abhipatnala]

Updated.

[maxsmythe]

This is an example of a good comment -- the why of this code is not obvious and depends on external considerations

[maxsmythe]

stale comment

[abhipatnala]

Deleted.

[maxsmythe]

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.

[abhipatnala]

Updated the logic to use status gate