title: helm rollback fails to identify the failed deployments when re-triggered
body: <p>I have a scenario like below,
  Have two releases - Release-A and Release-B.</p>
  <p>Currently, I am on Release-A and need an upgrade of all the microservices to Release-B.
  I tried performing the helm upgrade of microservice - &quot;mymicroservice&quot; with the below command to deliver Release-B.</p>
  <pre><code>helm --kubeconfig /home/config upgrade --namespace testing --install --wait mymicroservice mymicroservice-release-b.tgz
  </code></pre>
  <p>Because of some issue, the deployment object got failed to install and went into an error state.</p>
  <p>Observing this, I perform the below rollback command.</p>
  <pre><code>helm --kubeconfig /home/config --namespace testing rollback mymicroservice
  </code></pre>
  <p>Due to some issue(may be an intermittent system failure or user behavior), the Release-A's deployment object also went into failed/Crashloopbackoff state.Although this will result in helm rollback success, the deployment object is still not entered the running state.</p>
  <p>Once I made the necessary corrections, I will retry the rollback. As the deployment spec is already updated with helm, it never attempts to re-install the deployment objects even if it is in the failed state.</p>
  <p>Is there any option with Helm to handle the above scenarios ?.</p>
  <p>Tried with <code>--force</code> flag, but there are other errors related to Service object replace in the microservice when used the --force flag approach.</p>
  <pre><code>Rollback &quot;mymicroservice -monitoring&quot; failed: failed to replace object: Service &quot;mymicroservice-monitoring&quot; is invalid: spec.clusterIP: Invalid value: &quot;&quot;: field is immutable
  </code></pre>