local blob deployer doc (gardener#958)

* guided tour documentation

* remove note about local blobs not working with deployers

docs/guided-tour/blueprints/helm-chart-resource/README.md

@@ -30,14 +30,37 @@ The list of resources of the component descriptor within the component version h
 blueprint and one for the Helm chart. The entry for the Helm chart has the name `hello-world-chart` and contains the 
 address in the OCI registry.
 
-> **_NOTE:_** Adding resources other than the blueprints as local blobs to the component version is not
-> supported by the landscaper, yet.  
-> This is because the deployers currently fetch the image based on the
-> access information templated into the deploy item (as shown below) without knowledge of a corresponding
-> component version. This information is not sufficient to resolve local blobs.
+## Referencing the Helm Chart
+The deploy execution in the [blueprint](./blueprint/blueprint.yaml) can be modified so that it references a specific
+resource from the component with a *resource key*.
+> **_NOTE:_** For now, this resource key is merely a base64 encoded global resource identity (= component name, 
+> component version and the resource identity, which consists at least of the resource name). This information
+> might be useful for debugging purposes.  
+> **But since this will likely change in the future, for all intends and purposes BUT debugging, you should view the 
+> *resource key* as an opaque key!**
+
+#### Go Templating with Path Expression
+The `getResourceKey` function can parse a component descriptor path expression of the following form:
+`cd://<keyword>/<value>/<keyword>/<value>/...`  
+with the **keywords** `componentReferences` and `resources`.
+
+In the most simple case, where the [component](./component-archive/v2-external/component-descriptor.yaml) referenced in 
+the [installation](./installation/installation.yaml) directly contains the helm chart resource itself (as it is the case
+here), this results in the following path:
+
+```yaml
+chart:
+  resourceRef: {{ getResourceKey `cd://resources/hello-world-chart` }}
+```
 
+As this function uses [ocm](https://ocm.software/) to fetch the corresponding resource, you can even switch the
+storage technology (more often referred to as access type in the context of ocm) - thus, e.g. store the helm chart in a
+helm repository instead of an oci registry - without having to adjust the blueprint (You will of course have to adjust
+the access in the corresponding component version). It even allows you to store your helm chart as a local blob as part
+of the component!
 
-## Referencing the Helm Chart
+> **_DEPRECATED_:** The following explains how this use case has typically been covered before the `getResourceKey()` 
+> templating function has been introduced.
 
 The deploy execution in the [blueprint](./blueprint/blueprint.yaml) has been modified so that it takes the Helm chart 
 address from the component descriptor:
@@ -71,8 +94,34 @@ The procedure to install the helm chart with Landscaper is the same as before:
    kubectl apply -f <path to installation.yaml>
    ```
 
+## Remark on Referencing Helm Charts
+Theoretically, it is possible that the name of a *component reference* or a *resource* is not sufficient to uniquely
+identify them within a component. The [ocm specification](https://github.com/open-component-model/ocm-spec/blob/main/doc/01-model/03-elements-sub.md#identifiers)  
+defines that the identity of references as well as resources may optionally also contain a *version* and an 
+*extraIdentity* (see following [component configuration file](https://ocm.software/docs/guides/getting-started-with-ocm/#all-in-one) 
+as an [example](./assets/components.yaml)).
+
+In such cases, the resource cannot be specified with a path expression. Instead, it has to be specified as defined in 
+the [guidelines of the ocm specification](https://github.com/open-component-model/ocm-spec/blob/main/doc/05-guidelines/03-references.md).
+The corresponding part of the deploy execution looks like this:
+
+```yaml
+chart:
+  resourceRef: {{ getResourceKey `
+    resource:
+      name: ocmcli
+      version: v0.5.0
+      extraIdentity:
+        architecture: amd64
+        os: linux
+`}}
+```
+
+> **_NOTE:_** Here, you have to be careful with the indentation, as the input string has to be valid yaml.
 
 ## Remark on Charts Stored in a Helm Chart Repository
+> **_DEPRECATED_:** This use case can be covered with the `getResourceKey()` templating function in a more convenient 
+> way.
 
 Let us mention a variation of this example. Above, we have stored our Helm chart in an OCI registry as described in
 [Use OCI-based registries](https://helm.sh/docs/topics/registries/).

docs/guided-tour/blueprints/helm-chart-resource/assets/components.yaml

@@ -0,0 +1,26 @@
+component:
+  name: github.com/open-component-model/ocmcli
+  version: 0.5.0
+  provider:
+    name: ocm.software
+  resources:
+    - name: ocmcli
+      version: v0.5.0
+      access:
+        imageReference: ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image_linux_amd64:0.5.0
+        type: ociRegistry
+      relation: external
+      type: ociImage
+      extraIdentity:
+        architecture: amd64
+        os: linux
+    - name: ocmcli
+      version: v0.5.0
+      access:
+        imageReference: ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image_linux_arm64:0.5.0
+        type: ociRegistry
+      relation: external
+      type: ociImage
+      extraIdentity:
+        architecture: arm64
+        os: linux