Best practices for updating status

[mattmoor]

Today we have updateStatus calls scattered throughout reconciliation. We should consider standardizing on a better pattern for this, which gives us a strong sense that it's being reliably updated.

[evankanderson]

Additionally, it might make sense to standardize the GetCondition helpers to return a zero-initialized object, rather than a *Condition which might be nil. That would allow usage like:

if status.GetCondition(myCondition).Status != corev1.ConditionTrue {
  ...
}

as opposed to:

s := status.GetCondition(myCondition)
if s != nil && s.Status != corev1.ConditionTrue {  // have to remember and read nil check

}

[dprotaso]

Also from working on the subresources PR #786 we should migrate status updates for our CRDs to use the generated UpdateStatus clientset call

ie. for revision

serving/pkg/client/clientset/versioned/typed/serving/v1alpha1/revision.go

Line 37 in e1b3aae

UpdateStatus(*v1alpha1.Revision) (*v1alpha1.Revision, error)

Just need to confirm it works without the CustomResourceSubresources feature gate enabled.

[mattmoor]

@evankanderson This is very peripherally related to your comment: #1118. I've managed to make SetCondition private on 2/4 types so far (the 2 harder ones).

[mattmoor]

tl;dr I am going to close this

My recent refactorings have netted us a single call to updateStatus per controller, which is essentially the first-order cleanup that this issue wanted fixed (previously we called it like it was our job!).

I believe there is further work that can be done to improve this (as @dprotaso indicates) by transitioning the implementation of this to UpdateStatus once we're on 1.11.