This relates to a discussion @mikedanese, @davidopp, and I had yesterday.

Also related: #14961 (controllerRef, observedGeneration), #22007 (controller annotation of managed resources)

I effectively added expiration to RS and RC. However, pod creation appears to be fairly slow, so the timeout needs to be long.

#22138 sets the timeout to 5 minutes.

It also eliminates expectations from Deployment.

Is this about the need for refcounting in the RC manager, or something larger? The issues hint at a unified theory of controllers much larger than the adhoc implementation of expectations that has been cargo culted around.

The RCs need to be precise, so they need to refcount. Not all controllers have the same requirements. Fwiw in the controllers I've written (ingress/service) I've just invented different synchronization mechanisms of my own using annotations. I believe leaving this upto the controller author should work for the 60% case.

I'd like to make the RC and RS controllers have deterministic/idempotent behavior.

We already made deletion idempotent by ensuring victims to delete are chosen deterministically.

I'd like to do the same for creation by making pod names deterministic.

I don't want to use dense indices, however, since that would have misleading connotations. However, we could do something like hash the pod template with a monotonic counter. Deployment takes the max of outstanding revisions and adds one (but doesn't use it in object names) and uses the pod template hash in the RS name. RC/RS could take the max of outstanding incarnations, add one, and hash that with the pod template. As with Deployment revisions, incarnations could be recorded as annotations (on the pods, in this case).

Would need to rewrite incarnation annotations in the case of adoption.

See also #7369

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

/remove-lifecycle rotten
/lifecycle frozen

Is this issue still one we'd want to track and work on?

I haven't looked at reported bugs for a long time, but probably we can close this in favor of addressing user-reported issues, if any.

/close

@bgrant0607: Closing this issue.