feat: add observedGeneration to CommonStatus

[sdowell]

This updates the built in CommonStatus struct to provide observedGeneration behavior when using one of the provided status builders. Custom implementations of the BuildStatus interface could already set observedGeneration if desired, but this provides an opinionated default to the addon implementations.

What this PR does / why we need it: Sets status.observedGeneration for the built-in CommonStatus type. This makes it easier to determine when a KDP controller which uses the Addon object has reconciled the current spec of the managed resource.

Which issue(s) this PR fixes:
Fixes #391

[k8s-ci-robot]

Hi @sdowell. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[tomasaschan]

/ok-to-test

Thanks! I need to wrap my head around what happens for users who already define ObservedGenerarion and also use CommonStatus, when they upgrade to a version that has this patch - will they get a build error? Runtime error? Or will it just work? - but other than that it looks great!

[sdowell]

/ok-to-test

Thanks! I need to wrap my head around what happens for users who already define ObservedGenerarion and also use CommonStatus, when they upgrade to a version that has this patch - will they get a build error? Runtime error? Or will it just work? - but other than that it looks great!

My understanding is that the intended pattern of using the Addon object structs (CommonStatus/CommonSpec) is to embed the addon struct(s) into your CRD struct.

If a user upgrades to the new k-d-p version and already defined an observedGeneration field on their CRD, there would now be duplicate entries of observedGeneration on the struct. For example:

type Status struct {
	addonv1alpha1.CommonStatus     `json:",inline"`
	// +kubebuilder:default:=0
	ObservedGeneration int64 `json:"observedGeneration"`
}

My understanding is that it shouldn't encounter any build errors and the already defined field should take precedence for marshalling/unmarshalling. In this case I think the recommendation would be to replace the already defined field with the CommonStatus builtin to avoid confusion.

And if they didn't already have an observedGeneration field on their struct, it would be added upon upgrading.

[tomasaschan]

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sdowell, tomasaschan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [tomasaschan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment