Merge branch 'main' into RHIDP-5409-consistent-titles-subtitles

Author: themr0c

artifacts/attributes.adoc

@@ -27,6 +27,7 @@
 :my-product-database-certificates-secrets: my-rhdh-database-certificates-secrets
 :my-product-database-secrets: my-rhdh-database-secrets
 :my-product-url: https://__<my_developer_hub_url>__
+:my-extra-file-configmap: my-project-configmap
 
 // Red Hat Platforms
 :ocp-brand-name: Red Hat OpenShift Container Platform

artifacts/rhdh-plugins-reference/jfrog-artifactory/jfrog-artifactory-plugin-admin.adoc

@@ -0,0 +1,53 @@
+[id="installing-configuring-jfrog-artifactory_{context}"]
+= Installing and configuring the JFrog Artifactory plugin
+
+JFrog Artifactory is a front-end plugin that displays the information about your container images stored in the JFrog Artifactory repository. The JFrog Artifactory plugin is preinstalled with {product-short} and disabled by default. To use it, you need to enable and configure it first.
+
+[IMPORTANT]
+====
+The JFrog Artifactory plugin is a Technology Preview feature only.
+
+Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend using them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
+
+For more information on Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/[Technology Preview Features Scope].
+
+Additional detail on how Red Hat provides support for bundled community dynamic plugins is available on the https://access.redhat.com/policy/developerhub-support-policy[Red Hat Developer Support Policy] page.
+====
+
+== Installation
+The JFrog Artifactory plugin is preinstalled in {product-short} with basic configuration properties. To enable it, set the disabled property to `false` as follows:
+
+[source,yaml]
+----
+global:
+  dynamic:
+    includes:
+      - dynamic-plugins.default.yaml
+    plugins:
+      - package: ./dynamic-plugins/dist/backstage-community-plugin-jfrog-artifactory
+        disabled: false
+----
+
+== Configuration
+. Set the proxy to the desired JFrog Artifactory server in the `app-config.yaml` file as follows:
++
+[source,yaml]
+----
+proxy:
+  endpoints:
+    ‘/jfrog-artifactory/api’:
+      target: http://<hostname>:8082 # or https://<customer>.jfrog.io
+      headers:
+      # Authorization: 'Bearer <YOUR TOKEN>'
+      # Change to "false" in case of using a self-hosted Artifactory instance with a self-signed certificate
+      secure: true
+----
+
+. Add the following annotation to the entity’s `catalog-info.yaml` file to enable the JFrog Artifactory plugin features in RHDH components:
++
+[source,yaml]
+----
+metadata:
+    annotations:
+      'jfrog-artifactory/image-name': '<IMAGE-NAME>'
+----

artifacts/rhdh-plugins-reference/jfrog-artifactory/jfrog-artifactory-plugin-user.adoc

@@ -0,0 +1,31 @@
+[id="using-jfrog-artifactory_{context}"]
+= Using the JFrog Artifactory plugin
+
+The JFrog Artifactory plugin displays information about your container images within the Jfrog Artifactory registry.
+
+[IMPORTANT]
+====
+The JFrog Artifactory plugin is a Technology Preview feature only.
+
+Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend using them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
+
+For more information on Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/[Technology Preview Features Scope].
+
+Additional detail on how Red Hat provides support for bundled community dynamic plugins is available on the https://access.redhat.com/policy/developerhub-support-policy[Red Hat Developer Support Policy] page.
+====
+
+.Prerequisites
+
+* Your {product-short} application is installed and running.
+* You have enabled the JFrog Artifactory plugin. 
+
+.Procedure
+
+. Open your {product-short} application and select a component from the *Catalog* page.
+. Go to the *Image Registry* tab.
+
++
+The *Image Registry* tab contains a list of container images within your Jfrog Artifactory repository and related information, such as *Version*, *Repositories*, *Manifest*, *Modified*, and *Size*.
+
++
+image::rhdh-plugins-reference/jfrog-artifactory.png[image-registry-tab-jfrog-artifactory]

assemblies/assembly-provisioning-a-custom-configuration.adoc

@@ -22,6 +22,7 @@ include::modules/configuring/proc-provisioning-your-custom-configuration.adoc[le
 
 include::modules/configuring/proc-using-the-operator-to-run-rhdh-with-your-custom-configuration.adoc[leveloffset=+1]
 
+include::modules/configuring/proc-mounting-additional-files-in-your-custom-configuration-using-rhdh-operator.adoc[leveloffset=+2]
 
 include::modules/configuring/proc-using-the-helm-chart-to-run-rhdh-with-your-custom-configuration.adoc[leveloffset=+1]
 

assemblies/dynamic-plugins/assembly-configuring-rhdh-plugins.adoc

@@ -7,6 +7,9 @@ include::../modules/dynamic-plugins/con-ansible-plugin-admin.adoc[leveloffset=+1
 // Argo CD
 include::../../artifacts/rhdh-plugins-reference/argocd/argocd-plugin-admin.adoc[leveloffset=+1]
 
+//JFrog Artifactory
+include::../../artifacts/rhdh-plugins-reference/jfrog-artifactory/jfrog-artifactory-plugin-admin.adoc[leveloffset=+1]
+
 // Keycloak
 include::../../artifacts/rhdh-plugins-reference/keycloak/keycloak-plugin-admin.adoc[leveloffset=+1]
 

assemblies/dynamic-plugins/assembly-using-rhdh-plugins.adoc

@@ -7,6 +7,9 @@ include::../modules/dynamic-plugins/con-ansible-plugin-user.adoc[leveloffset=+1]
 // Argo CD
 include::../../artifacts/rhdh-plugins-reference/argocd/argocd-plugin-user.adoc[leveloffset=+1]
 
+//JFrog Artifactory
+include::../../artifacts/rhdh-plugins-reference/jfrog-artifactory/jfrog-artifactory-plugin-user.adoc[leveloffset=+1]
+
 // Keycloak
 include::../../artifacts/rhdh-plugins-reference/keycloak/keycloak-plugin-user.adoc[leveloffset=+1]
 

images/rhdh-plugins-reference/jfrog-artifactory.png

@@ -81,7 +81,7 @@ $ oc create configmap rbac-policies \
 
 .. Select *Add Backstage container additional volume mounts* and add the following values:
 
-mountPath:: `/opt/app-root/src`
+mountPath:: `/opt/app-root/src/rbac`
 Name:: `rbac-policies`
 
 .. Add the RBAC policy to the *Backstage container additional volumes* in the {product-short} Helm Chart:

modules/authorization/proc-defining-authorizations-in-external-files-by-using-helm.adoc

@@ -0,0 +1,77 @@
+[id="mounting-additional-files-in-your-custom-configuration-using-rhdh-operator"]
+= Mounting additional files in your custom configuration using the {product} Operator
+
+You can use the {product-short} Operator to mount extra files, such as a ConfigMap or Secret, to the container in a preferred location.
+
+The `mountPath` field specifies the location where a ConfigMap or Secret is mounted. The behavior of the mount, whether it includes or excludes a `subPath`, depends on the specification of the `key` or `mountPath` fields.
+
+* If `key` and `mountPath` are not specified: Each key or value is mounted as a `filename` or content with a `subPath`.
+* If `key` is specified with or without `mountPath`: The specified key or value is mounted with a `subPath`.
+* If only `mountPath` is specified: A directory containing all the keys or values is mounted without a `subPath`.
+
+[NOTE]
+====
+* {ocp-short} does not automatically update a volume mounted with `subPath`. By default, the {product-very-short} operator monitors these ConfigMaps or Secrets and refreshes the {product-very-short} Pod when changes occur.
+* For security purposes, {product} does not give the Operator Service Account read access to Secrets. As a result, mounting files from Secrets without specifying both mountPath and key is not supported.
+====
+
+
+.Prerequisites
+* You have developer permissions to access the {ocp-short} cluster containing your {product-short} instance using the {openshift-cli}.
+* link:{installing-on-ocp-book-url}[Your {ocp-short} administrator has installed the {product} Operator in {ocp-short}].
+
+.Procedure
+
+. In {ocp-short}, create your ConfigMap or Secret with the following YAML codes:
++
+.Minimal `{my-extra-file-configmap}` ConfigMap example
+====
+[source,yaml,subs="+attributes,+quotes"]
+----
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: {my-extra-file-configmap}
+data:
+  file11.txt: |
+    My file11 content
+  file 12.txt: |
+    My file12 content
+----
+====
++
+.Minimal `{my-product-secrets}` Secret example
+====
+[source,yaml,subs="+attributes,+quotes"]
+----
+apiVersion: v1
+kind: Secret
+metadata:
+  name: {my-product-secrets}
+StringData:
+  secret11.txt: |
+    secret-content
+----
+====
+For more information, see xref:provisioning-your-custom-configuration[Provisioning and using your custom {product} configuration].
+
+. Set the value of the `configMaps name` to the name of the ConfigMap or `secrets name` to the name of the Secret in your `{product-custom-resource-type}` CR. For example:
++
+====
+[source,yaml,subs="+attributes,+quotes"]
+----
+spec:
+  application:
+    extraFiles:
+      mountPath: /my/path
+      configMaps:
+        - name: {my-extra-file-configmap}
+          key: file12.txt
+          mountPath: /my/my-rhdh-config-map/path
+      secrets:
+        - name: {my-product-secrets}
+          key: secret11.txt
+          mountPath: /my/my-rhdh-secret/path
+
+----
+====

modules/configuring/proc-mounting-additional-files-in-your-custom-configuration-using-rhdh-operator.adoc

@@ -20,15 +20,15 @@ Containers are available for the following CPU architectures:
 .Prerequisites
 
 * You are logged in as an administrator on the {ocp-short} web console.
-* You have configured the appropriate roles and permissions within your project to create or access an application. For more information, see the link:https://docs.openshift.com/container-platform/{ocp-version}/applications/index.html[{ocp-brand-name} documentation on Building applications].
+* You have configured the appropriate roles and permissions within your project to create or access an application. For more information, see the link:https://docs.redhat.com/en/documentation/openshift_container_platform/{ocp-version}/html-single/building_applications/index#building-applications-overview[{ocp-brand-name} documentation on Building applications].
 
 [IMPORTANT]
 ====
 For enhanced security, better control over the Operator lifecycle, and preventing potential privilege escalation, install the {product} Operator in a dedicated default `rhdh-operator` namespace. You can restrict other users' access to the Operator resources through role bindings or cluster role bindings.
 
-You can also install the Operator in another namespace by creating the necessary resources, such as an Operator group. For more information, see link:https://docs.openshift.com/container-platform/latest/operators/admin/olm-adding-operators-to-cluster.html#olm-installing-global-namespaces_olm-adding-operators-to-a-cluster[Installing global Operators in custom namespaces].
+You can also install the Operator in another namespace by creating the necessary resources, such as an Operator group. For more information, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/{ocp-version}/html-single/operators/index#olm-installing-global-namespaces_olm-adding-operators-to-a-cluster[Installing global Operators in custom namespaces].
 
-However, if the {product} Operator shares a namespace with other Operators, then it shares the same update policy as well, preventing the customization of the update policy. For example, if one Operator is set to manual updates, the {product} Operator update policy is also set to manual. For more information, see link:https://docs.openshift.com/container-platform/latest/operators/understanding/olm/olm-colocation.html#olm-colocation-namespaces_olm-colocation[Colocation of Operators in a namespace].
+However, if the {product} Operator shares a namespace with other Operators, then it shares the same update policy as well, preventing the customization of the update policy. For example, if one Operator is set to manual updates, the {product} Operator update policy is also set to manual. For more information, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/{ocp-version}/html-single/operators/index#olm-colocation-namespaces_olm-colocation[Colocation of Operators in a namespace].
 
 ====
 
@@ -62,4 +62,4 @@ The `fast` channel includes all of the updates available for a particular versio
 .Additional resources
 
 * xref:proc-install-rhdh-ocp-operator_{context}[Deploying {product} on {ocp-short} with the Operator]
-* link:https://docs.openshift.com/container-platform/{ocp-version}/operators/admin/olm-adding-operators-to-cluster.html#olm-installing-from-operatorhub-using-web-console_olm-adding-operators-to-a-cluster[Installing from OperatorHub using the web console]
+* link:https://docs.redhat.com/en/documentation/openshift_container_platform/{ocp-version}/html-single/operators/index#olm-installing-from-operatorhub-using-web-console_olm-adding-operators-to-a-cluster[Installing from OperatorHub by using the web console]