feat: add status back-reporting support (1/, work applier side)

[michaelawyu]

Description of your changes

This PR adds support for status back-reporting on the work applier side.

I have:

• Run make reviewable to ensure this PR is ready for review.

How has this code been tested

• Unit tests
• Integration tests

Special notes for your reviewer

E2E tests are only possible when the full flow has been implemented.

[codecov]

Codecov Report

❌ Patch coverage is 81.48148% with 5 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
pkg/controllers/workapplier/status.go	81.48%	4 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[weng271190436]

if the AppliedWork object is supposed to be gone at this point. And you check the owner reference of the namespace right before, which includes getting the applied work from memberClient1.

What happened between checkNSOwnerReferences(workName, nsName) and appliedWorkRemovedActual := appliedWorkRemovedActual(workName, nsName) that caused the AppliedWork to be removed between these 2 statements?

[michaelawyu]

Hi Wei! This was kind of related to an earlier issue we discussed a while ago. The integration test uses the envtest package, which runs a somewhat trimmed down Kubernetes environment. Specifically in this environment, IIRC when we do the foreground deletion there is no controller to actually delete the child objects, and owner references will not be updated as well (even if the owner itself is already gone), which is the reason why the corrent code formation works. I am happy to explain this a bit further if needed -> Britania might have a bit more context though as she added this part of the code.

[weng271190436]

My confusion is that this function

func appliedWorkRemovedActual(workName, nsName string) func() error {
	return func() error {
		// Retrieve the AppliedWork object.
		appliedWork := &fleetv1beta1.AppliedWork{}
		if err := memberClient1.Get(ctx, client.ObjectKey{Name: workName}, appliedWork); err != nil {
			if errors.IsNotFound(err) {
				// The AppliedWork object has been deleted, which is expected.
				return nil
			}
			return fmt.Errorf("failed to retrieve the AppliedWork object: %w", err)
		}
		if !appliedWork.DeletionTimestamp.IsZero() && controllerutil.ContainsFinalizer(appliedWork, metav1.FinalizerDeleteDependents) {
			// The AppliedWork object is being deleted, but the finalizer is still present. Remove the finalizer as there
			// are no real built-in controllers in this test environment to handle garbage collection.
			controllerutil.RemoveFinalizer(appliedWork, metav1.FinalizerDeleteDependents)
			Expect(memberClient1.Update(ctx, appliedWork)).To(Succeed(), "Failed to remove the finalizer from the AppliedWork object")
		}
		return fmt.Errorf("appliedWork object still exists")
	}
}

doesn't delete anything unless it is the removal of the finalizer that resulted in a successful deletion?

[michaelawyu]

Hi Wei! Yeah, the work applier, when seeing that a work object has been deleted, will attempt to remove its corresponding AppliedWork object.