I'm hitting a couple issues with the helm install/upgrade/rollback wait logic:

1. maxUnavailable is subtracted from the amount of pods that need to be ready when waiting for deployments and daemonsets. It seems to me that maxUnavailable is only about how to accomplish the update, and should not dictate when the update is considered complete. If there is only 1 replica and the default maxUnavailable of 1 is in place, then it will wait for 1-1 == 0 pods to be ready, which is not ideal.

2. status.observedGeneration is not accounted for, so this can lead to race conditions where the wait logic sees the pods from the old generation of the deployment or daemonset rather than the new one.

It looks like 1. came out of #5219 and a similar issue to 2. is mentioned there as well though it doesn't specifically mention observedGeneration ( cc @thomastaylor312 )

Since the wait logic does not reliably wait for all pods to be updated/ready it seems to be of limited use, and gives a false impression that the release is good to go. Would there be any interest in removing the maxUnavailable subtraction and/or adding a status.observedGeneration check?