<p>I have situation where I am deploying some chart, let's call it &quot;myChart&quot;.</p>
<p>Let's suppose I have a pipeline, where I am doing below:</p>
<pre><code>helm delete myChart_1.2 -n &lt;myNamespace&gt;
</code></pre>
<p>An <strong>right after</strong> I am installing new one:</p>
<pre><code>helm delete myChart_1.3 -n &lt;myNamespace&gt;
</code></pre>
<p>Does Kubernetes or maybe Helm knows that all the resources should be deleted first and then install new?</p>
<p>For instance there might be some PVC and PV that are still not deleted. Is there any problem with that, should I add some waits before deployment?</p>

<p>Helm delete (aka. uninstall) should remove the objects managed in a given deployment, before exiting.</p>
<p>Still, when the command returns: you could be left with resources in a Terminating state, pending actual deletion.</p>
<p>Usually, we could find about PVC, that may still be attached to a running container.</p>
<p>Or objects such as ReplicaSet or Pods -- most likely, your Helm chart installs Deployments, DaemonSets, StatefulSets, ... top-level objects may appear to be deleted, while their child objects are still being terminated.</p>
<p>Although this shouldn't be an issue for Helm, assuming that your application is installed using a generated name, and as long as your chart is able to create multiple instances of a same application, in a same cluster/namespace, ... without them overlapping ( =&gt; if all resources managed through Helm have unique names, which is not always the case ).</p>
<p>If your chart is hosted on a public repository, let us know what to check. And if you're not one of the maintainer for that chart: beware that Helm charts could go from amazing to very bad, depending on who's contributing, what use cases have been met so far, ...</p>
