docs: mounting volumes, secrets and configmaps for devworkspaces

modules/administration-guide/examples/system-variables.adoc

@@ -658,7 +658,7 @@ Default::: `+<username>-che+`
 
 == `+CHE_INFRA_KUBERNETES_NAMESPACE_LABEL+`
 
-Defines whether che-server should try to label the workspace namespaces.
+Defines whether che-server should try to label the workspace namespaces. NOTE: It is strongly recommended to keep the value of this property set to true. If false, the new workspace namespaces will not be labeled automatically and therefore not recognized by the {prod-short} operator making some features of DevWorkspaces not working. If false, an administrator is required to label the namespaces manually using the labels specified in che.infra.kubernetes.namespace.labels. If you want to manage the namespaces yourself, make sure to follow \https://www.eclipse.org/che/docs/stable/administration-guide/provisioning-namespaces-in-advance/. Any additional labels present on the namespace are kept in place and do not affect the functionality. Also note that the the administrator is free to pre-create and label the namespaces manually even if this property is true. No updates to the namespaces are done if they already conform to the labeling requirements.
 
 Default::: `+true+`
 
@@ -676,7 +676,7 @@ Default::: `+true+`
 
 == `+CHE_INFRA_KUBERNETES_NAMESPACE_LABELS+`
 
-List of labels to find {orch-namespace} that are used for {prod-short} Workspaces. They are used to:  - find prepared {orch-namespace} for users in combination with `che.infra.kubernetes.namespace.annotations`.  - actively label {orch-namespace} with any workspace.
+List of labels to find {orch-namespace} that are used for {prod-short} Workspaces. They are used to:  - find prepared {orch-namespace} for users in combination with `che.infra.kubernetes.namespace.annotations`.  - actively label {orch-namespace} with any workspace. NOTE: It is strongly recommended not to change the value of this property because the {prod-short} operator relies on these labels and their precise values when reconciling DevWorkspaces. If this configuration is changed, the namespaces will not be automatically recognized by the {prod-short} operator as workspace namespaces unless manually labeled as such using the default labels and values. Additional labels on the namespace do not affect the functionality.
 
 Default::: `+app.kubernetes.io/part-of=che.eclipse.org,app.kubernetes.io/component=workspaces-namespace+`
 

modules/end-user-guide/nav.adoc

@@ -10,11 +10,12 @@
 ** xref:basic-actions-you-can-perform-on-a-workspace.adoc[]
 * xref:selecting-an-ide.adoc[]
 * xref:customizing-workspaces-components.adoc[]
-* xref:configuring-user-preferences-and-secrets.adoc[]
-** xref:configuring-user-secrets.adoc[]
-** xref:secret-as-a-file.adoc[]
-** xref:secret-as-a-variable.adoc[]
-** xref:git-credential-store.adoc[]
+* xref:using-credentials-and-configurations-in-workspaces.adoc[]
+** xref:using-a-git-credentials-store.adoc[]
+** xref:creating-image-pull-secrets.adoc[]
+** xref:mounting-secrets.adoc[]
+** xref:mounting-configmaps.adoc[]
+* xref:requesting-persistent-storage-for-workspaces.adoc[] 
 * xref:integrating-with-kubernetes.adoc[]
 ** xref:automatic-token-injection.adoc[]
 ** xref:navigating-che-from-openshift-developer-perspective.adoc[]

modules/end-user-guide/pages/creating-image-pull-secrets.adoc

@@ -0,0 +1,15 @@
+:_content-type: ASSEMBLY
+:navtitle: Creating image pull Secrets
+:keywords: user-guide, configuring, user, secrets
+:page-aliases: 
+
+[id="image-pull-secrets_{context}"]
+= Creating image pull Secrets
+
+To allow the `{devworkspace}` Pods in the {orch-name} cluster of your organization's {prod-short} instance to access container registries that require authentication, create an image pull Secret.
+
+You can create image pull Secrets by using `{orch-cli}` or a `.dockercfg` file or a `config.json` file.
+
+include::partial$proc_creating-an-image-pull-secret-with-cli.adoc[leveloffset=+1]
+include::partial$proc_creating-an-image-pull-secret-from-a-.dockercfg-file.adoc[leveloffset=+1]
+include::partial$proc_creating-an-image-pull-secret-from-a-config.json-file.adoc[leveloffset=+1]

modules/end-user-guide/pages/mounting-configmaps.adoc

@@ -0,0 +1,80 @@
+:navtitle: Mounting ConfigMaps
+:keywords: user-guide, configuring, user, configmaps, configmap, mounting, mount
+:page-aliases:
+
+[id="mounting-configmaps_{context}"]
+= Mounting ConfigMaps
+
+To mount non-confidential configuration data into your workspaces, use {kubernetes} ConfigMaps.
+
+Using {kubernetes} ConfigMaps, you can mount non-sensitive data such as configuration values for an application.
+
+Mount {kubernetes} ConfigMaps to the `{devworkspace}` containers in the {orch-name} cluster of your organization's {prod-short} instance.
+
+.Prerequisites
+
+* You have GUI or CLI access to the {orch-name} cluster of your organization's {prod-short} instance.
+* You have created a new ConfigMap or determined an existing one in your user {orch-namespace} to mount to all `{devworkspace}` containers.
+* For CLI users: The `{orch-cli}` command line tool is installed in the operating system you are using.
+
+.Procedure
+
+. Determine an existing ConfigMap in your user {orch-namespace} to mount to all workspace containers.
+
+. Set the required labels for mounting.
++
+[TIP]
+====
+CLI users can run `{orch-cli}`:
+
+[subs="+quotes,+attributes,+macros"]
+----
+$ {orch-cli} label configmap __<ConfigMap_name>__ \
+        controller.devfile.io/mount-to-devworkspace=true \
+        controller.devfile.io/watch-configmap=true
+----
+====
+
+. Optional: Use the annotations to configure how the ConfigMap is mounted.
++
+.Optional annotations
+|===
+|Annotation | Description
+
+|`controller.devfile.io/mount-path:`
+| Specifies the mount path.
+
+Defaults to `/etc/config/__<ConfigMap_name>__`.
+
+|`controller.devfile.io/mount-as:`
+| Specifies how the resource should be mounted: `file`, `subpath`, or `env`.
+
+Defaults to `file`.
+
+`mount-as:file` mounts the keys and values as files within the mount path.
+
+`mount-as:subpath` mounts the keys and values within the mount path using subpath volume mounts.
+
+`mount-as:env` mounts the keys and values as environment variables in all `{devworkspace}` containers.
+|===
+
+.Mounting a ConfigMap as environment variables
+====
+[source,yaml,subs="+quotes"]
+----
+kind: ConfigMap
+apiVersion: v1
+metadata:
+  name: my-settings
+  labels:
+    controller.devfile.io/mount-to-devworkspace: 'true'
+    controller.devfile.io/watch-configmap: 'true'
+  annotations:
+    controller.devfile.io/mount-as: env
+data:
+  __<env_var_1>__: __<value_1>__
+  __<env_var_2>__: __<value_2>__
+----
+
+When you start a workspace, the `__<env_var_1>__` and `__<env_var_2>__` environment variables will be available in the `{devworkspace}` containers.
+====