<p>Currently, I have 2 Helm Charts - Chart A, and Chart B. Both Chart A and Chart B have the same dependency on a Redis instance, as defined in the <code>Chart.yaml</code> file:</p>

<pre><code>dependencies:
- name: redis
  version: 1.1.21
  repository: https://kubernetes-charts.storage.googleapis.com/
</code></pre>

<p>I have also overwritten Redis's name since applying the 2 Charts consecutively results in 2 Redis instances, as such:</p>

<pre><code>redis:
  fullnameOverride: "redis"
</code></pre>

<p>When I try to install Chart A and then Chart B I get the following error:</p>

<p><code>Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: kind: PersistentVolumeClaim, namespace: default, name: redis</code></p>

<p>I was left with the impression that 2 charts with identical dependencies would use the same instance if it's already present?</p>

Zomtorg
<p>When you install a chart using Helm, it generally expects each <em>release</em> to have its own self-contained set of Kubernetes objects.  In the basic example you show, I'd expect to see Kubernetes Service objects named something like</p>

<pre><code>release-a-application-a
release-a-redis
release-b-application-b
release-b-redis
</code></pre>

<p>There is a general convention that objects are named starting with <code>{{ .Release.Name }}</code>, so the two Redises are separate.</p>

<p>This is actually an expected setup.  A typical rule of building microservices is that each service contains its own isolated storage, and that services never share storage with each other.  This Helm pattern supports that, and there's not really a disadvantage to having this setup.</p>

<p>If you really want the two charts to share a single Redis installation, you can write an "umbrella" chart that doesn't do anything on its own but depends on the two application charts.  The chart would have a <code>Chart.yaml</code> file and (in Helm 2) a <code>requirements.yaml</code> file that references the two other charts, but not a <code>templates</code> directory of its own.  That would cause Helm to conclude that a single Redis could support both applications, and you'd wind up with something like</p>

<pre><code>umbrella-application-a
umbrella-application-b
umbrella-redis
</code></pre>

<p>(In my experience you usually <em>don't</em> want this – you <em>do</em> want a separate Redis per application – and so trying to manage multiple installations using an umbrella chart doesn't work especially well.)</p>
