From 86ba56d0ef1bb7313cec5fe30c8c72bfb83a387f Mon Sep 17 00:00:00 2001 From: dfitzmau Date: Fri, 24 Oct 2025 11:12:57 +0100 Subject: [PATCH] CTEditor-z-to-the-r: Add missing module type tags to files starting with z-r --- contributing_to_docs/tools_and_setup.adoc | 1 + modules/recommended-node-host-practices.adoc | 1 + modules/recommended-scale-practices.adoc | 1 + modules/red-hat-marketplace-features.adoc | 1 + ...hentication-enabled-registry-overview.adoc | 1 + ...egistry-integrated-openshift-registry.adoc | 1 + ...onfiguration-resource-overview-aws-s3.adoc | 1 + ...nfiguration-resource-overview-gcp-gcs.adoc | 1 + ...ion-resource-overview-openstack-swift.adoc | 1 + ...istribution-across-availability-zones.adoc | 2 +- modules/registry-quay-overview.adoc | 1 + modules/registry-removed.adoc | 1 + .../sample-windows-workload-deployment.adoc | 1 + modules/samples-operator-configuration.adoc | 2 +- ...ng-virtual-hardware-update-on-vsphere.adoc | 1 + modules/sdpolicy-logging.adoc | 1 + modules/sdpolicy-monitoring.adoc | 1 + modules/sdpolicy-networking.adoc | 1 + modules/sdpolicy-platform.adoc | 1 + modules/sdpolicy-security.adoc | 1 + modules/sdpolicy-storage.adoc | 1 + modules/security-build-designing.adoc | 1 + modules/security-build-inputs.adoc | 20 +++++------ modules/security-build-knative.adoc | 1 + modules/security-build-management.adoc | 1 + modules/security-build-once.adoc | 1 + ...y-container-content-external-scanning.adoc | 1 + .../security-container-content-inside.adoc | 1 + .../security-container-content-scanning.adoc | 1 + .../security-container-content-universal.adoc | 1 + modules/security-deploy-continuous.adoc | 8 ++--- modules/security-deploy-image-sources.adoc | 1 + modules/security-deploy-signature.adoc | 1 + modules/security-deploy-trigger.adoc | 1 + modules/security-hardening-how.adoc | 2 +- modules/security-hardening-what.adoc | 2 +- modules/security-hosts-vms-openshift.adoc | 2 ++ modules/security-hosts-vms-rhcos.adoc | 1 + modules/security-hosts-vms-vs-containers.adoc | 1 + modules/security-platform-admission.adoc | 35 ++++++------------ modules/security-platform-authentication.adoc | 1 + modules/security-platform-certificates.adoc | 10 ++---- modules/security-platform-multi-tenancy.adoc | 29 +++++---------- modules/security-registries-ecosystem.adoc | 36 +++++-------------- modules/security-registries-immutable.adoc | 18 +++------- modules/security-registries-openshift.adoc | 9 ++--- modules/security-registries-quay.adoc | 2 ++ modules/security-registries-where.adoc | 6 ++-- modules/security-storage-block.adoc | 6 ++-- modules/security-storage-persistent.adoc | 1 + modules/security-storage-shared.adoc | 5 ++- .../security-understanding-containers.adoc | 1 + modules/security-understanding-openshift.adoc | 27 +++++--------- .../serverless-services-network-policies.adoc | 2 +- .../service-accounts-as-oauth-clients.adoc | 1 + modules/service-accounts-default.adoc | 1 + modules/service-accounts-granting-roles.adoc | 14 ++++---- modules/storage-ephemeral-storage-manage.adoc | 1 + .../storage-ephemeral-storage-monitoring.adoc | 10 +++--- modules/storage-ephemeral-storage-types.adoc | 16 ++------- ...ersistent-storage-aws-maximum-volumes.adoc | 1 + ...orage-persistent-storage-block-volume.adoc | 9 ++--- ...istent-storage-iscsi-custom-initiator.adoc | 10 ++++-- ...nt-storage-iscsi-enforcing-disk-quota.adoc | 10 +++--- ...ge-persistent-storage-iscsi-multipath.adoc | 14 ++++---- ...persistent-storage-iscsi-provisioning.adoc | 11 +++--- ...sistent-storage-iscsi-volume-security.adoc | 1 + .../storage-persistent-storage-lifecycle.adoc | 2 +- ...-storage-nfs-additional-configuration.adoc | 2 ++ ...tent-storage-nfs-enforcing-disk-quota.adoc | 3 +- ...tent-storage-nfs-reclaiming-resources.adoc | 1 + ...orage-persistent-storage-nfs-user-ids.adoc | 1 + ...ersistent-storage-nfs-volume-security.adoc | 26 +++++--------- modules/storage-persistent-storage-pv.adoc | 1 + .../storage-persistent-storage-reclaim.adoc | 8 +++-- ...rage-persistent-storage-volume-format.adoc | 11 +++--- .../strategies-for-s2i-troubleshooting.adoc | 31 +++++++++------- modules/support-network-trace-methods.adoc | 1 + modules/support.adoc | 1 + modules/templates-quickstart.adoc | 1 + modules/templates-using-the-cli.adoc | 1 + modules/templates-waiting-for-readiness.adoc | 30 +++++++++------- modules/templates-writing-description.adoc | 1 + modules/templates-writing-labels.adoc | 1 + modules/templates-writing-object-list.adoc | 1 + modules/templates-writing-parameters.adoc | 1 + modules/templates-writing.adoc | 1 + modules/threescale-backend-cache.adoc | 1 + modules/threescale-istio-adapter-apicast.adoc | 1 + modules/topology-manager-policies.adoc | 1 + ...ubleshooting-disabling-autoreboot-mco.adoc | 1 + modules/understanding-update-channels.adoc | 2 +- modules/unmanaged-operators.adoc | 1 + modules/update-preparing-evaluate-alerts.adoc | 9 +++-- modules/update-preparing-list.adoc | 1 + modules/update-preparing-migrate.adoc | 1 + modules/upi-installation-considerations.adoc | 1 + modules/virt-loki-log-queries.adoc | 1 - modules/web-console-configuration.adoc | 1 + modules/web-console-disable.adoc | 1 + modules/what-huge-pages-do.adoc | 1 + modules/windows-machineset-aws.adoc | 1 + modules/windows-machineset-azure.adoc | 1 + modules/windows-machineset-gcp.adoc | 1 + modules/windows-machineset-nutanix.adoc | 1 + modules/windows-machineset-vsphere.adoc | 1 + modules/windows-node-services.adoc | 1 + modules/windows-pod-placement.adoc | 1 + modules/windows-workload-management.adoc | 1 + modules/wmco-does-not-install.adoc | 1 + modules/wmco-supported-csi-drivers.adoc | 1 + modules/wmco-upgrades.adoc | 1 + snippets/technology-preview.adoc | 2 ++ 113 files changed, 261 insertions(+), 257 deletions(-) diff --git a/contributing_to_docs/tools_and_setup.adoc b/contributing_to_docs/tools_and_setup.adoc index 4ee69dd0d2ea..bff23f1b48df 100644 --- a/contributing_to_docs/tools_and_setup.adoc +++ b/contributing_to_docs/tools_and_setup.adoc @@ -1,5 +1,6 @@ [id="contributing-to-docs-tools-and-setup"] = Install and set up the tools and software + :icons: :toc: macro :toc-title: diff --git a/modules/recommended-node-host-practices.adoc b/modules/recommended-node-host-practices.adoc index 6ab4166d22fd..847254d21d6a 100644 --- a/modules/recommended-node-host-practices.adoc +++ b/modules/recommended-node-host-practices.adoc @@ -2,6 +2,7 @@ // // * post_installation_configuration/node-tasks.adoc +:_mod-docs-content-type: REFERENCE [id="recommended-node-host-practices_{context}"] = Recommended node host practices diff --git a/modules/recommended-scale-practices.adoc b/modules/recommended-scale-practices.adoc index 3611a5fb6522..28f01f6bf046 100644 --- a/modules/recommended-scale-practices.adoc +++ b/modules/recommended-scale-practices.adoc @@ -2,6 +2,7 @@ // // * scalability_and_performance/recommended-performance-scale-practices/recommended-control-plane-practices.adoc +:_mod-docs-content-type: CONCEPT [id="recommended-scale-practices_{context}"] = Recommended practices for scaling the cluster diff --git a/modules/red-hat-marketplace-features.adoc b/modules/red-hat-marketplace-features.adoc index 8e56bad71f58..e26ab5190461 100644 --- a/modules/red-hat-marketplace-features.adoc +++ b/modules/red-hat-marketplace-features.adoc @@ -2,6 +2,7 @@ // // * applications/red-hat-marketplace.adoc +:_mod-docs-content-type: CONCEPT [id="red-hat-marketplace-features_{context}"] = Red Hat Marketplace features diff --git a/modules/registry-authentication-enabled-registry-overview.adoc b/modules/registry-authentication-enabled-registry-overview.adoc index 239410707b6f..48728a5cd716 100644 --- a/modules/registry-authentication-enabled-registry-overview.adoc +++ b/modules/registry-authentication-enabled-registry-overview.adoc @@ -2,6 +2,7 @@ // // * registry/index.adoc +:_mod-docs-content-type: CONCEPT [id="registry-authentication-enabled-registry-overview_{context}"] = Authentication enabled Red Hat registry diff --git a/modules/registry-integrated-openshift-registry.adoc b/modules/registry-integrated-openshift-registry.adoc index 2d95297fac7d..c455ac38dc13 100644 --- a/modules/registry-integrated-openshift-registry.adoc +++ b/modules/registry-integrated-openshift-registry.adoc @@ -3,6 +3,7 @@ //* registry/registry-options //* registry/index.adoc +:_mod-docs-content-type: CONCEPT [id="registry-integrated-openshift-registry_{context}"] = Integrated {product-registry} diff --git a/modules/registry-operator-configuration-resource-overview-aws-s3.adoc b/modules/registry-operator-configuration-resource-overview-aws-s3.adoc index 880e81984597..bde5cb02e1d9 100644 --- a/modules/registry-operator-configuration-resource-overview-aws-s3.adoc +++ b/modules/registry-operator-configuration-resource-overview-aws-s3.adoc @@ -2,6 +2,7 @@ // // * registry/configuring-registry-storage-aws-user-infrastructure.adoc +:_mod-docs-content-type: REFERENCE [id="registry-operator-configuration-resource-overview-aws-s3_{context}"] = Image Registry Operator configuration parameters for AWS S3 diff --git a/modules/registry-operator-configuration-resource-overview-gcp-gcs.adoc b/modules/registry-operator-configuration-resource-overview-gcp-gcs.adoc index a267ca0f7c4c..d42943a8e849 100644 --- a/modules/registry-operator-configuration-resource-overview-gcp-gcs.adoc +++ b/modules/registry-operator-configuration-resource-overview-gcp-gcs.adoc @@ -2,6 +2,7 @@ // // * openshift_images/configuring-registry-operator.adoc +:_mod-docs-content-type: REFERENCE [id="registry-operator-configuration-resource-overview-gcp-gcs_{context}"] = Image Registry Operator configuration parameters for {gcp-short} GCS diff --git a/modules/registry-operator-configuration-resource-overview-openstack-swift.adoc b/modules/registry-operator-configuration-resource-overview-openstack-swift.adoc index 0c3293f80704..d49b9db22718 100644 --- a/modules/registry-operator-configuration-resource-overview-openstack-swift.adoc +++ b/modules/registry-operator-configuration-resource-overview-openstack-swift.adoc @@ -2,6 +2,7 @@ // // * registry/configuring_registry_storage/configuring-registry-storage-openstack-user-infrastructure.adoc +:_mod-docs-content-type: REFERENCE [id="registry-operator-configuration-resource-overview-openstack-swift_{context}"] = Image Registry Operator configuration parameters for {rh-openstack} Swift diff --git a/modules/registry-operator-distribution-across-availability-zones.adoc b/modules/registry-operator-distribution-across-availability-zones.adoc index 812d4cdd75ad..8d9e5a15c32b 100644 --- a/modules/registry-operator-distribution-across-availability-zones.adoc +++ b/modules/registry-operator-distribution-across-availability-zones.adoc @@ -2,7 +2,7 @@ // // * openshift_images/configuring-registry-operator.adoc - +:_mod-docs-content-type: REFERENCE [id="registry-operator-distribution-across-availability-zones_{context}"] = Image Registry Operator distribution across availability zones diff --git a/modules/registry-quay-overview.adoc b/modules/registry-quay-overview.adoc index 458bb51dcb3a..0fd785da1531 100644 --- a/modules/registry-quay-overview.adoc +++ b/modules/registry-quay-overview.adoc @@ -2,6 +2,7 @@ // // * registry/index.adoc +:_mod-docs-content-type: CONCEPT [id="registry-quay-overview_{context}"] = {quay} registries diff --git a/modules/registry-removed.adoc b/modules/registry-removed.adoc index a7775f248d06..15022dcd847d 100644 --- a/modules/registry-removed.adoc +++ b/modules/registry-removed.adoc @@ -15,6 +15,7 @@ // * registry/configuring_registry_storage/configuring-registry-storage-baremetal.adoc // * registry/configuring_registry_storage/configuring-registry-storage-vsphere.adoc +:_mod-docs-content-type: CONCEPT [id="registry-removed_{context}"] = Image registry removed during installation diff --git a/modules/sample-windows-workload-deployment.adoc b/modules/sample-windows-workload-deployment.adoc index 1505fefe21d6..3b7593e2f247 100644 --- a/modules/sample-windows-workload-deployment.adoc +++ b/modules/sample-windows-workload-deployment.adoc @@ -2,6 +2,7 @@ // // * windows_containers/scheduling-windows-workloads.adoc +:_mod-docs-content-type: REFERENCE [id="sample-windows-workload-deployment_{context}"] = Sample Windows container workload deployment diff --git a/modules/samples-operator-configuration.adoc b/modules/samples-operator-configuration.adoc index e3d502c0836d..6adf538d8eb0 100644 --- a/modules/samples-operator-configuration.adoc +++ b/modules/samples-operator-configuration.adoc @@ -2,7 +2,7 @@ // // * openshift_images/configuring_samples_operator.adoc - +:_mod-docs-content-type: REFERENCE [id="samples-operator-configuration_{context}"] = Cluster Samples Operator configuration parameters diff --git a/modules/scheduling-virtual-hardware-update-on-vsphere.adoc b/modules/scheduling-virtual-hardware-update-on-vsphere.adoc index 829e7eed8826..e660cbe8fc05 100644 --- a/modules/scheduling-virtual-hardware-update-on-vsphere.adoc +++ b/modules/scheduling-virtual-hardware-update-on-vsphere.adoc @@ -2,6 +2,7 @@ // // updating/updating_a_cluster/updating-hardware-on-nodes-running-in-vsphere.adoc +:_mod-docs-content-type: CONCEPT [id="scheduling-virtual-hardware-update-on-vsphere_{context}"] = Scheduling an update for virtual hardware on vSphere diff --git a/modules/sdpolicy-logging.adoc b/modules/sdpolicy-logging.adoc index be5f073fb404..8ec9ffbe3f1d 100644 --- a/modules/sdpolicy-logging.adoc +++ b/modules/sdpolicy-logging.adoc @@ -2,6 +2,7 @@ // // * osd_architecture/osd_policy/osd-service-definition.adoc +:_mod-docs-content-type: CONCEPT [id="sdpolicy-logging_{context}"] = Logging {product-title} provides optional integrated log forwarding to Amazon CloudWatch (on AWS) or {gcp-full} Logging (on {gcp-short}). diff --git a/modules/sdpolicy-monitoring.adoc b/modules/sdpolicy-monitoring.adoc index 109a2a4a9dc9..e6c21a336d59 100644 --- a/modules/sdpolicy-monitoring.adoc +++ b/modules/sdpolicy-monitoring.adoc @@ -2,6 +2,7 @@ // // * osd_architecture/osd_policy/osd-service-definition.adoc +:_mod-docs-content-type: CONCEPT [id="sdpolicy-monitoring_{context}"] = Monitoring diff --git a/modules/sdpolicy-networking.adoc b/modules/sdpolicy-networking.adoc index 298655fc48d1..ff507b445c67 100644 --- a/modules/sdpolicy-networking.adoc +++ b/modules/sdpolicy-networking.adoc @@ -2,6 +2,7 @@ // // * osd_architecture/osd_policy/osd-service-definition.adoc +:_mod-docs-content-type: CONCEPT [id="sdpolicy-networking_{context}"] = Networking diff --git a/modules/sdpolicy-platform.adoc b/modules/sdpolicy-platform.adoc index 7dd05d24ffc5..26d495b66e75 100644 --- a/modules/sdpolicy-platform.adoc +++ b/modules/sdpolicy-platform.adoc @@ -3,6 +3,7 @@ // // * osd_architecture/osd_policy/osd-service-definition.adoc +:_mod-docs-content-type: REFERENCE [id="sdpolicy-platform_{context}"] = Platform diff --git a/modules/sdpolicy-security.adoc b/modules/sdpolicy-security.adoc index e7b4a2c6e33c..664ed7e98d70 100644 --- a/modules/sdpolicy-security.adoc +++ b/modules/sdpolicy-security.adoc @@ -2,6 +2,7 @@ // // * osd_architecture/osd_policy/osd-service-definition.adoc +:_mod-docs-content-type: CONCEPT [id="sdpolicy-security_{context}"] = Security diff --git a/modules/sdpolicy-storage.adoc b/modules/sdpolicy-storage.adoc index 796396ef1d4d..24465a13904b 100644 --- a/modules/sdpolicy-storage.adoc +++ b/modules/sdpolicy-storage.adoc @@ -3,6 +3,7 @@ // // * osd_architecture/osd_policy/osd-service-definition.adoc +:_mod-docs-content-type: CONCEPT [id="sdpolicy-storage_{context}"] = Storage diff --git a/modules/security-build-designing.adoc b/modules/security-build-designing.adoc index c3e64d774e4e..e3b880b23c74 100644 --- a/modules/security-build-designing.adoc +++ b/modules/security-build-designing.adoc @@ -2,6 +2,7 @@ // // * security/container_security/security-build.adoc +:_mod-docs-content-type: CONCEPT [id="security-build-designing_{context}"] = Designing your build process diff --git a/modules/security-build-inputs.adoc b/modules/security-build-inputs.adoc index 9d554ab5b815..9ba0a040abf2 100644 --- a/modules/security-build-inputs.adoc +++ b/modules/security-build-inputs.adoc @@ -2,21 +2,18 @@ // // * security/container_security/security-build.adoc +:_mod-docs-content-type: PROCEDURE [id="security-build-inputs_{context}"] = Securing inputs during builds -In some scenarios, build operations require credentials to access dependent -resources, but it is undesirable for those credentials to be available in the -final application image produced by the build. You can define input secrets for -this purpose. +In some scenarios, build operations require credentials to access dependent resources, but it is undesirable for those credentials to be available in the final application image produced by the build. You can define input secrets for this purpose. -For example, when building a Node.js application, you can set up your private -mirror for Node.js modules. To download modules from that private -mirror, you must supply a custom `.npmrc` file for the build that contains -a URL, user name, and password. For security reasons, you do not want to expose -your credentials in the application image. +For example, when building a Node.js application, you can set up your private mirror for Node.js modules. To download modules from that private mirror, you must supply a custom `.npmrc` file for the build that contains +a URL, user name, and password. For security reasons, you do not want to expose your credentials in the application image. -Using this example scenario, you can add an input secret to a new `BuildConfig` object: +Using this example scenario, you can add an input secret to a new `BuildConfig` object. + +.Procedure . Create the secret, if it does not exist: + @@ -25,8 +22,7 @@ Using this example scenario, you can add an input secret to a new `BuildConfig` $ oc create secret generic secret-npmrc --from-file=.npmrc=~/.npmrc ---- + -This creates a new secret named `secret-npmrc`, which contains the base64 -encoded content of the `~/.npmrc` file. +This creates a new secret named `secret-npmrc`, which contains the base64 encoded content of the `~/.npmrc` file. . Add the secret to the `source` section in the existing `BuildConfig` object: + diff --git a/modules/security-build-knative.adoc b/modules/security-build-knative.adoc index a6af459810ba..5f913640c850 100644 --- a/modules/security-build-knative.adoc +++ b/modules/security-build-knative.adoc @@ -2,6 +2,7 @@ // // * security/container_security/security-build.adoc +:_mod-docs-content-type: CONCEPT [id="security-build-knative_{context}"] = Building Knative serverless applications diff --git a/modules/security-build-management.adoc b/modules/security-build-management.adoc index 5a78524c37a1..930da6a7842f 100644 --- a/modules/security-build-management.adoc +++ b/modules/security-build-management.adoc @@ -2,6 +2,7 @@ // // * security/container_security/security-build.adoc +:_mod-docs-content-type: CONCEPT [id="security-build-management_{context}"] = Managing builds diff --git a/modules/security-build-once.adoc b/modules/security-build-once.adoc index c8da471f6fe7..d5320acfae5d 100644 --- a/modules/security-build-once.adoc +++ b/modules/security-build-once.adoc @@ -2,6 +2,7 @@ // // * security/container_security/security-build.adoc +:_mod-docs-content-type: CONCEPT [id="security-build-once_{context}"] = Building once, deploying everywhere diff --git a/modules/security-container-content-external-scanning.adoc b/modules/security-container-content-external-scanning.adoc index db71a53014aa..be7a33241a4c 100644 --- a/modules/security-container-content-external-scanning.adoc +++ b/modules/security-container-content-external-scanning.adoc @@ -2,6 +2,7 @@ // // * security/container_security/security-container-content.adoc +:_mod-docs-content-type: REFERENCE [id="security-container-content-external-scanning_{context}"] = Integrating external scanning diff --git a/modules/security-container-content-inside.adoc b/modules/security-container-content-inside.adoc index b54f8c227c93..9e73d58b5788 100644 --- a/modules/security-container-content-inside.adoc +++ b/modules/security-container-content-inside.adoc @@ -2,6 +2,7 @@ // // * security/container_security/security-container-content.adoc +:_mod-docs-content-type: CONCEPT [id="security-container-content-inside_{context}"] = Securing inside the container diff --git a/modules/security-container-content-scanning.adoc b/modules/security-container-content-scanning.adoc index 16ce56fd1ff6..80cc3f33de22 100644 --- a/modules/security-container-content-scanning.adoc +++ b/modules/security-container-content-scanning.adoc @@ -2,6 +2,7 @@ // // * security/container_security/security-container-content.adoc +:_mod-docs-content-type: CONCEPT [id="security-container-content-scanning_{context}"] = Security scanning in {op-system-base} diff --git a/modules/security-container-content-universal.adoc b/modules/security-container-content-universal.adoc index 3234a70f7caa..a74169a90d54 100644 --- a/modules/security-container-content-universal.adoc +++ b/modules/security-container-content-universal.adoc @@ -2,6 +2,7 @@ // // * security/container_security/security-container-content.adoc +:_mod-docs-content-type: CONCEPT [id="security-container-content-universal_{context}"] = Creating redistributable images with UBI diff --git a/modules/security-deploy-continuous.adoc b/modules/security-deploy-continuous.adoc index 710e8d3f17f9..c6f1e90b1e2c 100644 --- a/modules/security-deploy-continuous.adoc +++ b/modules/security-deploy-continuous.adoc @@ -2,12 +2,10 @@ // // * security/container_security/security-deploy.adoc +:_mod-docs-content-type: CONCEPT [id="security-deploy-continuous_{context}"] = Automating continuous deployment -You can integrate your own continuous deployment (CD) tooling with -{product-title}. +You can integrate your own continuous deployment (CD) tooling with {product-title}. -By leveraging CI/CD and {product-title}, you can automate the process of -rebuilding the application to incorporate the latest fixes, testing, and -ensuring that it is deployed everywhere within the environment. +By leveraging CI/CD and {product-title}, you can automate the process of rebuilding the application to incorporate the latest fixes, testing, and ensuring that it is deployed everywhere within the environment. diff --git a/modules/security-deploy-image-sources.adoc b/modules/security-deploy-image-sources.adoc index 586a392999a2..f17c4e3c252c 100644 --- a/modules/security-deploy-image-sources.adoc +++ b/modules/security-deploy-image-sources.adoc @@ -2,6 +2,7 @@ // // * security/container_security/security-deploy.adoc +:_mod-docs-content-type: REFERENCE [id="security-deploy-image-sources_{context}"] = Controlling what image sources can be deployed diff --git a/modules/security-deploy-signature.adoc b/modules/security-deploy-signature.adoc index fb27fe47bb19..7a59cea6a060 100644 --- a/modules/security-deploy-signature.adoc +++ b/modules/security-deploy-signature.adoc @@ -2,6 +2,7 @@ // // * security/container_security/security-deploy.adoc +:_mod-docs-content-type: CONCEPT [id="security-deploy-signature_{context}"] = Using signature transports diff --git a/modules/security-deploy-trigger.adoc b/modules/security-deploy-trigger.adoc index 47159e5d63ad..7d6220c1ae28 100644 --- a/modules/security-deploy-trigger.adoc +++ b/modules/security-deploy-trigger.adoc @@ -2,6 +2,7 @@ // // * security/container_security/security-deploy.adoc +:_mod-docs-content-type: CONCEPT [id="security-deploy-trigger_{context}"] = Controlling container deployments with triggers diff --git a/modules/security-hardening-how.adoc b/modules/security-hardening-how.adoc index 2c92ed576b46..a734b9aa0bce 100644 --- a/modules/security-hardening-how.adoc +++ b/modules/security-hardening-how.adoc @@ -2,8 +2,8 @@ // // * security/container_security/security-hardening.adoc +:_mod-docs-content-type: CONCEPT [id="security-hardening-how_{context}"] - = Choosing how to harden {op-system} Direct modification of {op-system} systems in {product-title} is discouraged. Instead, you should think of modifying systems in pools of nodes, such as worker nodes and control plane nodes. When a new node is needed, in non-bare metal installs, you can request a new node of the type you want and it will be created from an {op-system} image plus the modifications you created earlier. diff --git a/modules/security-hardening-what.adoc b/modules/security-hardening-what.adoc index 31af3c6d0c97..0bf10eeed5d7 100644 --- a/modules/security-hardening-what.adoc +++ b/modules/security-hardening-what.adoc @@ -2,8 +2,8 @@ // // * security/container_security/security-hardening.adoc +:_mod-docs-content-type: CONCEPT [id="security-hardening-what_{context}"] - = Choosing what to harden in {op-system} ifdef::openshift-origin[] For information on how to approach security for any {op-system-base} system, see the link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9#Security[Security] category in the Red{nbsp}Hat Enterprise Linux 9 documentation. diff --git a/modules/security-hosts-vms-openshift.adoc b/modules/security-hosts-vms-openshift.adoc index da34b450234a..fd48060dd1e7 100644 --- a/modules/security-hosts-vms-openshift.adoc +++ b/modules/security-hosts-vms-openshift.adoc @@ -2,8 +2,10 @@ // // * security/container_security/security-hosts-vms.adoc +:_mod-docs-content-type: CONCEPT [id="security-hosts-vms-openshift_{context}"] = Securing {product-title} + When you deploy {product-title}, you have the choice of an installer-provisioned infrastructure (there are several available platforms) or your own user-provisioned infrastructure. diff --git a/modules/security-hosts-vms-rhcos.adoc b/modules/security-hosts-vms-rhcos.adoc index bfde587bdd5d..bb0d9e6f86ae 100644 --- a/modules/security-hosts-vms-rhcos.adoc +++ b/modules/security-hosts-vms-rhcos.adoc @@ -2,6 +2,7 @@ // // * security/container_security/security-hosts-vms.adoc +:_mod-docs-content-type: CONCEPT [id="security-hosts-vms-rhcos_{context}"] = Securing containers on {op-system-first} diff --git a/modules/security-hosts-vms-vs-containers.adoc b/modules/security-hosts-vms-vs-containers.adoc index a1339c49c0bf..507b14d623a9 100644 --- a/modules/security-hosts-vms-vs-containers.adoc +++ b/modules/security-hosts-vms-vs-containers.adoc @@ -2,6 +2,7 @@ // // * security/container_security/security-hosts-vms.adoc +:_mod-docs-content-type: CONCEPT [id="security-hosts-vms-vs-containers_{context}"] = Comparing virtualization and containers diff --git a/modules/security-platform-admission.adoc b/modules/security-platform-admission.adoc index 376f3bd9899f..72ac9ffa206e 100644 --- a/modules/security-platform-admission.adoc +++ b/modules/security-platform-admission.adoc @@ -2,33 +2,24 @@ // // * security/container_security/security-platform.adoc +:_mod-docs-content-type: CONCEPT [id="security-platform-admission_{context}"] = Protecting control plane with admission plugins -While RBAC controls access rules between users and groups and available projects, -_admission plugins_ define access to the {product-title} master API. -Admission plugins form a chain of rules that consist of: +While RBAC controls access rules between users and groups and available projects, _admission plugins_ define access to the {product-title} master API. Admission plugins form a chain of rules that consist of: -* Default admissions plugins: These implement a default set of -policies and resources limits that are applied to components of the {product-title} -control plane. +* Default admissions plugins: These implement a default set of policies and resources limits that are applied to components of the {product-title} control plane. -* Mutating admission plugins: These plugins dynamically extend the admission chain. -They call out to a webhook server and can both authenticate a request and modify the selected resource. +* Mutating admission plugins: These plugins dynamically extend the admission chain. They call out to a webhook server and can both authenticate a request and modify the selected resource. -* Validating admission plugins: These validate requests for a selected resource -and can both validate the request and ensure that the resource does not change again. +* Validating admission plugins: These validate requests for a selected resource and can both validate the request and ensure that the resource does not change again. -API requests go through admissions plugins in a chain, with any failure along -the way causing the request to be rejected. Each admission plugin is associated with particular resources and only -responds to requests for those resources. +API requests go through admissions plugins in a chain, with any failure along the way causing the request to be rejected. Each admission plugin is associated with particular resources and only responds to requests for those resources. [id="security-deployment-sccs_{context}"] == Security context constraints (SCCs) -You can use _security context constraints_ (SCCs) to define a set of conditions -that a pod must run with to be accepted -into the system. +You can use _security context constraints_ (SCCs) to define a set of conditions that a pod must run with to be accepted into the system. Some aspects that can be managed by SCCs include: @@ -38,21 +29,17 @@ Some aspects that can be managed by SCCs include: - SELinux context of the container - Container user ID -If you have the required permissions, you can adjust the default SCC policies to -be more permissive, if required. +If you have the required permissions, you can adjust the default SCC policies to be more permissive, if required. [id="security-service-account_{context}"] == Granting roles to service accounts -You can assign roles to service accounts, in the same way that -users are assigned role-based access. -There are three default service accounts created for each project. -A service account: +You can assign roles to service accounts, in the same way that users are assigned role-based access. +There are three default service accounts created for each project. A service account: * is limited in scope to a particular project * derives its name from its project * is automatically assigned an API token and credentials to access the OpenShift Container Registry -Service accounts associated with platform components automatically -have their keys rotated. +Service accounts associated with platform components automatically have their keys rotated. diff --git a/modules/security-platform-authentication.adoc b/modules/security-platform-authentication.adoc index efd74c85d105..00157cdb36d8 100644 --- a/modules/security-platform-authentication.adoc +++ b/modules/security-platform-authentication.adoc @@ -2,6 +2,7 @@ // // * security/container_security/security-platform.adoc +:_mod-docs-content-type: CONCEPT [id="security-platform-authentication_{context}"] = Authentication and authorization diff --git a/modules/security-platform-certificates.adoc b/modules/security-platform-certificates.adoc index f65dc39c266a..84d5f6f21cfa 100644 --- a/modules/security-platform-certificates.adoc +++ b/modules/security-platform-certificates.adoc @@ -2,13 +2,11 @@ // // * security/container_security/security-platform.adoc +:_mod-docs-content-type: CONCEPT [id="security-platform-certificates_{context}"] = Managing certificates for the platform -{product-title} has multiple components within its framework that use REST-based -HTTPS communication leveraging encryption via TLS certificates. -{product-title}'s installer configures these certificates during -installation. There are some primary components that generate this traffic: +{product-title} has multiple components within its framework that use REST-based HTTPS communication leveraging encryption via TLS certificates. {product-title}'s installer configures these certificates during installation. There are some primary components that generate this traffic: * masters (API server and controllers) * etcd @@ -19,6 +17,4 @@ installation. There are some primary components that generate this traffic: [id="security-platform-config-custom-certs_{context}"] == Configuring custom certificates -You can configure custom serving certificates for the public hostnames of the -API server and web console during initial installation or when redeploying -certificates. You can also use a custom CA. +You can configure custom serving certificates for the public hostnames of the API server and web console during initial installation or when redeploying certificates. You can also use a custom CA. diff --git a/modules/security-platform-multi-tenancy.adoc b/modules/security-platform-multi-tenancy.adoc index a1df1b2d6d5c..4aedc0bebe21 100644 --- a/modules/security-platform-multi-tenancy.adoc +++ b/modules/security-platform-multi-tenancy.adoc @@ -2,34 +2,21 @@ // // * security/container_security/security-platform.adoc +:_mod-docs-content-type: CONCEPT [id="security-platform-multi-tenancy_{context}"] = Isolating containers with multitenancy -Multitenancy allows applications on an {product-title} cluster that are owned -by multiple users, and run across multiple hosts and namespaces, -to remain isolated from each other and from outside attacks. -You obtain multitenancy by applying role-based access control (RBAC) +Multitenancy allows applications on an {product-title} cluster that are owned by multiple users, and run across multiple hosts and namespaces, +to remain isolated from each other and from outside attacks. You obtain multitenancy by applying role-based access control (RBAC) to Kubernetes namespaces. -In Kubernetes, _namespaces_ are areas where applications can run -in ways that are separate from other applications. -{product-title} uses and extends namespaces by adding extra -annotations, including MCS labeling in SELinux, and identifying -these extended namespaces as _projects_. Within the scope of -a project, users can maintain their own cluster resources, -including service accounts, policies, constraints, -and various other objects. +In Kubernetes, _namespaces_ are areas where applications can run in ways that are separate from other applications. {product-title} uses and extends namespaces by adding extra annotations, including MCS labeling in SELinux, and identifying these extended namespaces as _projects_. Within the scope of a project, users can maintain their own cluster resources, including service accounts, policies, constraints, and various other objects. -RBAC objects are assigned to projects to authorize selected users -to have access to those projects. That authorization takes the form -of rules, roles, and bindings: +RBAC objects are assigned to projects to authorize selected users to have access to those projects. That authorization takes the form of rules, roles, and bindings: -* Rules define what a user can create or access in a project. +* Rules define what a user can create or access in a project. * Roles are collections of rules that you can bind to selected users or groups. * Bindings define the association between users or groups and roles. -Local RBAC roles and bindings attach a user or group to a -particular project. Cluster RBAC can attach cluster-wide roles and bindings -to all projects in a cluster. There are default -cluster roles that can be assigned to provide `admin`, `basic-user`, `cluster-admin`, -and `cluster-status` access. +Local RBAC roles and bindings attach a user or group to a particular project. Cluster RBAC can attach cluster-wide roles and bindings +to all projects in a cluster. There are default cluster roles that can be assigned to provide `admin`, `basic-user`, `cluster-admin`, and `cluster-status` access. diff --git a/modules/security-registries-ecosystem.adoc b/modules/security-registries-ecosystem.adoc index d2ea7400f7f7..9cd8d8d0bf84 100644 --- a/modules/security-registries-ecosystem.adoc +++ b/modules/security-registries-ecosystem.adoc @@ -2,40 +2,20 @@ // // * security/container_security/security-registries.adoc +:_mod-docs-content-type: CONCEPT [id="security-registries-ecosystem_{context}"] = Getting containers from Red Hat Registry and Ecosystem Catalog -Red Hat lists certified container images for Red Hat products and partner offerings from the -link:https://catalog.redhat.com/software/containers/explore[Container Images] -section of the Red Hat Ecosystem Catalog. From that catalog, -you can see details of each image, including CVE, software packages listings, and health -scores. +Red Hat lists certified container images for Red Hat products and partner offerings from the link:https://catalog.redhat.com/software/containers/explore[Container Images] section of the Red Hat Ecosystem Catalog. From that catalog, you can see details of each image, including CVE, software packages listings, and health scores. -Red Hat images are actually stored in what is referred to as the _Red Hat Registry_, -which is represented by a public container registry (`registry.access.redhat.com`) -and an authenticated registry (`registry.redhat.io`). -Both include basically the same set of container images, with -`registry.redhat.io` including some additional images that require authentication -with Red Hat subscription credentials. +Red Hat images are actually stored in what is referred to as the _Red Hat Registry_, which is represented by a public container registry (`registry.access.redhat.com`) and an authenticated registry (`registry.redhat.io`). Both include basically the same set of container images, with +`registry.redhat.io` including some additional images that require authentication with Red Hat subscription credentials. -Container content is monitored for vulnerabilities by Red Hat and updated -regularly. When Red Hat releases security updates, such as fixes to _glibc_, -link:https://access.redhat.com/security/vulnerabilities/drown[DROWN], or -link:https://access.redhat.com/blogs/766093/posts/2757141[Dirty Cow], -any affected container images are also rebuilt and pushed -to the Red Hat Registry. +Container content is monitored for vulnerabilities by Red Hat and updated regularly. When Red Hat releases security updates, such as fixes to _glibc_, link:https://access.redhat.com/security/vulnerabilities/drown[DROWN], or link:https://access.redhat.com/blogs/766093/posts/2757141[Dirty Cow], any affected container images are also rebuilt and pushed to the Red Hat Registry. -Red Hat uses a `health index` to reflect the security risk for each container provided through -the Red Hat Ecosystem Catalog. Because containers consume software provided by Red -Hat and the errata process, old, stale containers are insecure whereas new, -fresh containers are more secure. +Red Hat uses a `health index` to reflect the security risk for each container provided through the Red Hat Ecosystem Catalog. Because containers consume software provided by Red Hat and the errata process, old, stale containers are insecure whereas new, fresh containers are more secure. -To illustrate the age of containers, the Red Hat Ecosystem Catalog uses a -grading system. A freshness grade is a measure of the oldest and most severe -security errata available for an image. "A" is more up to date than "F". See -link:https://access.redhat.com/articles/2803031[Container Health Index grades as used inside the Red Hat Ecosystem Catalog] for more details on this grading system. +To illustrate the age of containers, the Red Hat Ecosystem Catalog uses a grading system. A freshness grade is a measure of the oldest and most severe security errata available for an image. "A" is more up to date than "F". See link:https://access.redhat.com/articles/2803031[Container Health Index grades as used inside the Red Hat Ecosystem Catalog] for more details on this grading system. -See the link:https://access.redhat.com/security/[Red Hat Product Security Center] -for details on security updates and vulnerabilities related to Red Hat software. -Check out link:https://access.redhat.com/security/security-updates/#/security-advisories[Red Hat Security Advisories] +See the link:https://access.redhat.com/security/[Red Hat Product Security Center] for details on security updates and vulnerabilities related to Red Hat software. Check out link:https://access.redhat.com/security/security-updates/#/security-advisories[Red Hat Security Advisories] to search for specific advisories and CVEs. diff --git a/modules/security-registries-immutable.adoc b/modules/security-registries-immutable.adoc index ea70e016a38c..7bf7373295da 100644 --- a/modules/security-registries-immutable.adoc +++ b/modules/security-registries-immutable.adoc @@ -2,15 +2,11 @@ // // * security/container_security/security-registries.adoc +:_mod-docs-content-type: CONCEPT [id="security-registries-immutable_{context}"] = Immutable and certified containers -Consuming security updates is particularly important when managing _immutable -containers_. Immutable containers are containers that will never be changed -while running. When you deploy immutable containers, you do not step into the -running container to replace one or more binaries. From an operational -standpoint, you rebuild and redeploy an updated container image -to replace a container instead of changing it. +Consuming security updates is particularly important when managing _immutable containers_. Immutable containers are containers that will never be changed while running. When you deploy immutable containers, you do not step into the running container to replace one or more binaries. From an operational standpoint, you rebuild and redeploy an updated container image to replace a container instead of changing it. Red Hat certified images are: @@ -18,11 +14,5 @@ Red Hat certified images are: * Compatible across the {op-system-base} platforms, from bare metal to cloud * Supported by Red Hat -The list of known vulnerabilities is constantly evolving, so you must track the -contents of your deployed container images, as well as newly downloaded images, -over time. You can use -link:https://access.redhat.com/security/security-updates/#/security-advisories[Red Hat Security Advisories (RHSAs)] -to alert you to any newly discovered issues in -Red Hat certified container images, and direct you to the updated image. -Alternatively, you can go to the Red Hat Ecosystem Catalog -to look up that and other security-related issues for each Red Hat image. +The list of known vulnerabilities is constantly evolving, so you must track the contents of your deployed container images, as well as newly downloaded images, over time. You can use link:https://access.redhat.com/security/security-updates/#/security-advisories[Red Hat Security Advisories (RHSAs)] to alert you to any newly discovered issues in Red Hat certified container images, and direct you to the updated image. +Alternatively, you can go to the Red Hat Ecosystem Catalog to look up that and other security-related issues for each Red Hat image. diff --git a/modules/security-registries-openshift.adoc b/modules/security-registries-openshift.adoc index 7cdb0ec20698..368f40baa575 100644 --- a/modules/security-registries-openshift.adoc +++ b/modules/security-registries-openshift.adoc @@ -2,13 +2,10 @@ // // * security/container_security/security-registries.adoc +:_mod-docs-content-type: CONCEPT [id="security-registries-openshift_{context}"] = OpenShift Container Registry -{product-title} includes the _OpenShift Container Registry_, a private registry -running as an integrated component of the platform that you can use to manage your container -images. The OpenShift Container Registry provides role-based access controls -that allow you to manage who can pull and push which container images. +{product-title} includes the _OpenShift Container Registry_, a private registry running as an integrated component of the platform that you can use to manage your container images. The OpenShift Container Registry provides role-based access controls that allow you to manage who can pull and push which container images. -{product-title} also supports integration with other private registries that you might -already be using, such as {quay}. +{product-title} also supports integration with other private registries that you might already be using, such as {quay}. \ No newline at end of file diff --git a/modules/security-registries-quay.adoc b/modules/security-registries-quay.adoc index dcd3b208b580..4cd3c5cbffac 100644 --- a/modules/security-registries-quay.adoc +++ b/modules/security-registries-quay.adoc @@ -2,8 +2,10 @@ // // * security/container_security/security-registries.adoc +:_mod-docs-content-type: CONCEPT [id="security-registries-quay_{context}"] = Storing containers using {quay} + link:https://access.redhat.com/products/red-hat-quay[{quay}] is an enterprise-quality container registry product from Red Hat. Development for {quay} is done through the upstream diff --git a/modules/security-registries-where.adoc b/modules/security-registries-where.adoc index c493e3ad587d..5a8ef8a3cd3a 100644 --- a/modules/security-registries-where.adoc +++ b/modules/security-registries-where.adoc @@ -2,10 +2,8 @@ // // * security/container_security/security-registries.adoc +:_mod-docs-content-type: CONCEPT [id="security-registries-where_{context}"] = Knowing where containers come from? -There are tools you can use to scan and track the contents of your downloaded -and deployed container images. However, there are many public sources of -container images. When using public container registries, you can add a layer of -protection by using trusted sources. +There are tools you can use to scan and track the contents of your downloaded and deployed container images. However, there are many public sources of container images. When using public container registries, you can add a layer of protection by using trusted sources. diff --git a/modules/security-storage-block.adoc b/modules/security-storage-block.adoc index cfe322f5a73b..a8dc74230ebb 100644 --- a/modules/security-storage-block.adoc +++ b/modules/security-storage-block.adoc @@ -2,10 +2,8 @@ // // * security/container_security/security-storage.adoc +:_mod-docs-content-type: CONCEPT [id="security-network-storage-block_{context}"] = Block storage -For block storage providers like AWS Elastic Block Store (EBS), GCE Persistent -Disks, and iSCSI, {product-title} uses SELinux capabilities to secure the root -of the mounted volume for non-privileged pods, making the mounted volume owned -by and only visible to the container with which it is associated. +For block storage providers like AWS Elastic Block Store (EBS), GCE Persistent Disks, and iSCSI, {product-title} uses SELinux capabilities to secure the root of the mounted volume for non-privileged pods, making the mounted volume owned by and only visible to the container with which it is associated. diff --git a/modules/security-storage-persistent.adoc b/modules/security-storage-persistent.adoc index a576954f56e0..19909043380f 100644 --- a/modules/security-storage-persistent.adoc +++ b/modules/security-storage-persistent.adoc @@ -2,6 +2,7 @@ // // * security/container_security/security-storage.adoc +:_mod-docs-content-type: REFERENCE [id="security-network-storage-persistent_{context}"] = Persistent volume plugins diff --git a/modules/security-storage-shared.adoc b/modules/security-storage-shared.adoc index f6a654b456b0..86380503056f 100644 --- a/modules/security-storage-shared.adoc +++ b/modules/security-storage-shared.adoc @@ -2,10 +2,9 @@ // // * security/container_security/security-storage.adoc +:_mod-docs-content-type: CONCEPT [id="security-network-storage-shared_{context}"] = Shared storage For shared storage providers like NFS, the PV registers its -group ID (GID) as an annotation on the PV resource. Then, when the PV is claimed -by the pod, the annotated GID is added to the supplemental groups of the pod, -giving that pod access to the contents of the shared storage. +group ID (GID) as an annotation on the PV resource. Then, when the PV is claimed by the pod, the annotated GID is added to the supplemental groups of the pod, giving that pod access to the contents of the shared storage. diff --git a/modules/security-understanding-containers.adoc b/modules/security-understanding-containers.adoc index 3023556038ba..0d2254bdd390 100644 --- a/modules/security-understanding-containers.adoc +++ b/modules/security-understanding-containers.adoc @@ -2,6 +2,7 @@ // // * security/container_security/security-understanding.adoc +:_mod-docs-content-type: CONCEPT [id="security-understanding-containers_{context}"] = What are containers? diff --git a/modules/security-understanding-openshift.adoc b/modules/security-understanding-openshift.adoc index 74573db0b328..b437ebf7d880 100644 --- a/modules/security-understanding-openshift.adoc +++ b/modules/security-understanding-openshift.adoc @@ -2,28 +2,19 @@ // // * security/container_security/security-understanding.adoc +:_mod-docs-content-type: CONCEPT [id="security-understanding-openshift_{context}"] = What is {product-title}? -Automating how containerized applications are deployed, run, and managed is the -job of a platform such as {product-title}. At its core, {product-title} relies -on the Kubernetes project to provide the engine for orchestrating containers +Automating how containerized applications are deployed, run, and managed is the job of a platform such as {product-title}. At its core, {product-title} relies on the Kubernetes project to provide the engine for orchestrating containers across many nodes in scalable data centers. -Kubernetes is a project, which can run using different operating systems -and add-on components that offer no guarantees of supportability from the project. -As a result, the security of different Kubernetes platforms can vary. +Kubernetes is a project, which can run using different operating systems and add-on components that offer no guarantees of supportability from the project. As a result, the security of different Kubernetes platforms can vary. -{product-title} is designed to lock down Kubernetes security and integrate -the platform with a variety of extended components. To do this, -{product-title} draws on the extensive Red Hat ecosystem of open source -technologies that include the operating systems, authentication, storage, -networking, development tools, base container images, and many other -components. +{product-title} is designed to lock down Kubernetes security and integrate the platform with a variety of extended components. To do this, +{product-title} draws on the extensive Red Hat ecosystem of open source technologies that include the operating systems, authentication, storage, +networking, development tools, base container images, and many other components. -{product-title} can leverage Red Hat's experience in uncovering -and rapidly deploying fixes for vulnerabilities in the platform itself -as well as the containerized applications running on the platform. -Red Hat's experience also extends to efficiently integrating new -components with {product-title} as they become available and -adapting technologies to individual customer needs. +{product-title} can leverage Red Hat's experience in uncovering and rapidly deploying fixes for vulnerabilities in the platform itself +as well as the containerized applications running on the platform. Red Hat's experience also extends to efficiently integrating new +components with {product-title} as they become available and adapting technologies to individual customer needs. diff --git a/modules/serverless-services-network-policies.adoc b/modules/serverless-services-network-policies.adoc index 25f41ba02b86..f1c3d6602a9a 100644 --- a/modules/serverless-services-network-policies.adoc +++ b/modules/serverless-services-network-policies.adoc @@ -2,7 +2,7 @@ // // * serverless/knative-serving/config-applications/restrictive-cluster-policies.adoc -:_mod-docs-content-type: Concept +:_mod-docs-content-type: CONCEPT [id="serverless-services-network-policies_{context}"] = Clusters with restrictive network policies diff --git a/modules/service-accounts-as-oauth-clients.adoc b/modules/service-accounts-as-oauth-clients.adoc index f18f58656a8a..00b08452a572 100644 --- a/modules/service-accounts-as-oauth-clients.adoc +++ b/modules/service-accounts-as-oauth-clients.adoc @@ -2,6 +2,7 @@ // // * authentication/using-service-accounts-as-oauth-client.adoc +:_mod-docs-content-type: CONCEPT [id="service-accounts-as-oauth-clients_{context}"] = Service accounts as OAuth clients diff --git a/modules/service-accounts-default.adoc b/modules/service-accounts-default.adoc index 4bddcef57641..1e43cb140423 100644 --- a/modules/service-accounts-default.adoc +++ b/modules/service-accounts-default.adoc @@ -2,6 +2,7 @@ // // * authentication/using-service-accounts.adoc +:_mod-docs-content-type: REFERENCE [id="service-accounts-default_{context}"] = Default service accounts diff --git a/modules/service-accounts-granting-roles.adoc b/modules/service-accounts-granting-roles.adoc index bcab0ad027c5..e63d8c8c29ae 100644 --- a/modules/service-accounts-granting-roles.adoc +++ b/modules/service-accounts-granting-roles.adoc @@ -2,13 +2,16 @@ // // * authentication/using-service-accounts.adoc +:_mod-docs-content-type: PROCEDURE [id="service-accounts-granting-roles_{context}"] = Granting roles to service accounts You can grant roles to service accounts in the same way that you grant roles to a regular user account. -* You can modify the service accounts for the current project. For example, to add +.Procedure + +. You can modify the service accounts for the current project. For example, to add the `view` role to the `robot` service account in the `top-secret` project: + [source,terminal] @@ -38,10 +41,9 @@ subjects: ---- ==== -* You can also grant access to a specific service account in a project. For +. You can also grant access to a specific service account in a project. For example, from the project to which the service account belongs, use the `-z` flag and specify the `` - + [source,terminal] ---- @@ -77,9 +79,9 @@ subjects: ---- ==== -* To modify a different namespace, you can use the `-n` option to indicate the +. To modify a different namespace, you can use the `-n` option to indicate the project namespace it applies to, as shown in the following examples. - ++ ** For example, to allow all service accounts in all projects to view resources in the `my-project` project: + @@ -109,7 +111,7 @@ subjects: name: system:serviceaccounts ---- ==== - ++ ** To allow all service accounts in the `managers` project to edit resources in the `my-project` project: + diff --git a/modules/storage-ephemeral-storage-manage.adoc b/modules/storage-ephemeral-storage-manage.adoc index f392fed62cee..fe6ec141f40c 100644 --- a/modules/storage-ephemeral-storage-manage.adoc +++ b/modules/storage-ephemeral-storage-manage.adoc @@ -4,6 +4,7 @@ //* storage/understanding-ephemeral-storage.adoc //* microshift_storage/understanding-ephemeral-storage-microshift.adoc +:_mod-docs-content-type: CONCEPT [id=storage-ephemeral-storage-manage_{context}] = Ephemeral storage management diff --git a/modules/storage-ephemeral-storage-monitoring.adoc b/modules/storage-ephemeral-storage-monitoring.adoc index ef25a92bf39a..aea7a51340d5 100644 --- a/modules/storage-ephemeral-storage-monitoring.adoc +++ b/modules/storage-ephemeral-storage-monitoring.adoc @@ -3,21 +3,23 @@ // storage/understanding-persistent-storage.adoc[leveloffset=+1] //* microshift_storage/understanding-ephemeral-storage-microshift.adoc - +:_mod-docs-content-type: PROCEDURE [id=storage-ephemeral-storage-monitoring_{context}] = Monitoring ephemeral storage You can use `/bin/df` as a tool to monitor ephemeral storage usage on the volume where ephemeral container data is located, which is `/var/lib/kubelet` and `/var/lib/containers`. The available space for only `/var/lib/kubelet` is shown when you use the `df` command if `/var/lib/containers` is placed on a separate disk by the cluster administrator. -To show the human-readable values of used and available space in `/var/lib`, enter the following command: +.Procedure +* To show the human-readable values of used and available space in `/var/lib`, enter the following command: ++ [source,terminal] ---- $ df -h /var/lib ---- - ++ The output shows the ephemeral storage usage in `/var/lib`: - ++ .Example output [source,terminal] ---- diff --git a/modules/storage-ephemeral-storage-types.adoc b/modules/storage-ephemeral-storage-types.adoc index 98a02254fb3d..a3d766a6c68a 100644 --- a/modules/storage-ephemeral-storage-types.adoc +++ b/modules/storage-ephemeral-storage-types.adoc @@ -3,7 +3,7 @@ // storage/understanding-persistent-storage.adoc[leveloffset=+1] //* microshift_storage/understanding-ephemeral-storage-microshift.adoc - +:_mod-docs-content-type: REFERENCE [id=storage-ephemeral-storage-types_{context}] = Types of ephemeral storage @@ -14,19 +14,9 @@ partition: root and runtime. == Root -This partition holds the kubelet root directory, `/var/lib/kubelet/` by -default, and `/var/log/` directory. This partition can be shared between user -pods, the OS, and Kubernetes system daemons. This partition can be consumed by pods -through `EmptyDir` volumes, container logs, image layers, and container-writable -layers. Kubelet manages shared access and isolation of this partition. This -partition is ephemeral, and applications cannot expect any performance SLAs, -such as disk IOPS, from this partition. +This partition holds the kubelet root directory, `/var/lib/kubelet/` by default, and `/var/log/` directory. This partition can be shared between user pods, the OS, and Kubernetes system daemons. This partition can be consumed by pods through `EmptyDir` volumes, container logs, image layers, and container-writable layers. Kubelet manages shared access and isolation of this partition. This partition is ephemeral, and applications cannot expect any performance SLAs, such as disk IOPS, from this partition. == Runtime -This is an optional partition that runtimes can use for overlay -file systems. {product-title} attempts to identify and provide -shared access along with isolation to this partition. Container image -layers and writable layers are stored here. If the runtime partition -exists, the `root` partition does not hold any image layer or other writable storage. +This is an optional partition that runtimes can use for overlay file systems. {product-title} attempts to identify and provide shared access along with isolation to this partition. Container image layers and writable layers are stored here. If the runtime partition exists, the `root` partition does not hold any image layer or other writable storage. diff --git a/modules/storage-persistent-storage-aws-maximum-volumes.adoc b/modules/storage-persistent-storage-aws-maximum-volumes.adoc index 2357e0d3336f..d2f83449bd8a 100644 --- a/modules/storage-persistent-storage-aws-maximum-volumes.adoc +++ b/modules/storage-persistent-storage-aws-maximum-volumes.adoc @@ -2,6 +2,7 @@ // // * storage/persistent_storage-aws.adoc +:_mod-docs-content-type: REFERENCE [id="maximum-number-of-ebs-volumes-on-a-node_{context}"] = Maximum number of EBS volumes on a node diff --git a/modules/storage-persistent-storage-block-volume.adoc b/modules/storage-persistent-storage-block-volume.adoc index bbb5927d93a1..64816611b912 100644 --- a/modules/storage-persistent-storage-block-volume.adoc +++ b/modules/storage-persistent-storage-block-volume.adoc @@ -5,16 +5,13 @@ // This module should only be present in openshift-enterprise and // openshift-origin distributions. +:_mod-docs-content-type: REFERENCE [id="block-volume-support_{context}"] = Block volume support -{product-title} can statically provision raw block volumes. These volumes -do not have a file system, and can provide performance benefits for -applications that either write to the disk directly or implement their own -storage service. +{product-title} can statically provision raw block volumes. These volumes do not have a file system, and can provide performance benefits for applications that either write to the disk directly or implement their own storage service. -Raw block volumes are provisioned by specifying `volumeMode: Block` in the -PV and PVC specification. +Raw block volumes are provisioned by specifying `volumeMode: Block` in the PV and PVC specification. [IMPORTANT] ==== diff --git a/modules/storage-persistent-storage-iscsi-custom-initiator.adoc b/modules/storage-persistent-storage-iscsi-custom-initiator.adoc index 535b0b2657bc..3d4ec258a01d 100644 --- a/modules/storage-persistent-storage-iscsi-custom-initiator.adoc +++ b/modules/storage-persistent-storage-iscsi-custom-initiator.adoc @@ -2,14 +2,18 @@ // // * storage/persistent_storage-iscsi.adoc +:_mod-docs-content-type: PROCEDURE [id="iscsi-custom-iqn_{context}"] = iSCSI custom initiator IQN -Configure the custom initiator iSCSI Qualified Name (IQN) if the iSCSI -targets are restricted to certain IQNs, but the nodes that the iSCSI PVs + +Configure the custom initiator iSCSI Qualified Name (IQN) if the iSCSI targets are restricted to certain IQNs, but the nodes that the iSCSI PVs are attached to are not guaranteed to have these IQNs. -To specify a custom initiator IQN, use `initiatorName` field. +.Procedure + +* To specify a custom initiator IQN, update the `initiatorName` field in the `PersistentVolume` defintion object . +.Example PersistentVolume object with a value specified in the initiatorName field. [source,yaml] ---- apiVersion: v1 diff --git a/modules/storage-persistent-storage-iscsi-enforcing-disk-quota.adoc b/modules/storage-persistent-storage-iscsi-enforcing-disk-quota.adoc index df6141027efa..247360787b14 100644 --- a/modules/storage-persistent-storage-iscsi-enforcing-disk-quota.adoc +++ b/modules/storage-persistent-storage-iscsi-enforcing-disk-quota.adoc @@ -2,12 +2,12 @@ // // * storage/persistent_storage-iscsi.adoc +:_mod-docs-content-type: CONCEPT [id="enforcing-disk-quotas-iscsi_{context}"] -= Enforcing disk quotas -Use LUN partitions to enforce disk quotas and size constraints. Each LUN -is one persistent volume. Kubernetes enforces unique names for persistent += Enforce disk quotas + +Use LUN partitions to enforce disk quotas and size constraints. Each LUN is one persistent volume. Kubernetes enforces unique names for persistent volumes. -Enforcing quotas in this way allows the end user to request persistent -storage by a specific amount (for example, `10Gi`) and be matched with a +Enforcing quotas in this way allows the user to request persistent storage by a specific amount (for example, `10Gi`) and be matched with a corresponding volume of equal or greater capacity. diff --git a/modules/storage-persistent-storage-iscsi-multipath.adoc b/modules/storage-persistent-storage-iscsi-multipath.adoc index c1273b94ccd0..595e950041af 100644 --- a/modules/storage-persistent-storage-iscsi-multipath.adoc +++ b/modules/storage-persistent-storage-iscsi-multipath.adoc @@ -2,16 +2,18 @@ // // * storage/persistent_storage-iscsi.adoc +:_mod-docs-content-type: PROCEDURE [id="iscsi-multipath_{context}"] = iSCSI multipathing -For iSCSI-based storage, you can configure multiple paths by using the -same IQN for more than one target portal IP address. Multipathing ensures -access to the persistent volume when one or more of the components in a -path fail. -To specify multi-paths in the pod specification, use the `portals` field. -For example: +For iSCSI-based storage, you can configure multiple paths by using the same IQN for more than one target portal IP address. Multipathing ensures +access to the persistent volume when one or more of the components in a path fail. +.Procedure + +* To specify multi-paths in the pod specification, specify a value in the `portals` field of the `PersistentVolume` defintion object. + +.Example PersistentVolume object with a value specified in the portals field. [source,yaml] ---- apiVersion: v1 diff --git a/modules/storage-persistent-storage-iscsi-provisioning.adoc b/modules/storage-persistent-storage-iscsi-provisioning.adoc index c17a264b11d0..3794feca45c1 100644 --- a/modules/storage-persistent-storage-iscsi-provisioning.adoc +++ b/modules/storage-persistent-storage-iscsi-provisioning.adoc @@ -2,12 +2,15 @@ // // * storage/persistent_storage-iscsi.adoc +:_mod-docs-content-type: REFERENCE [id="persistent-storage-iscsi-provisioning_{context}"] = Provisioning -Verify that the storage exists in the underlying infrastructure before -mounting it as a volume in {product-title}. All that is required for the -iSCSI is the iSCSI target portal, a valid iSCSI Qualified Name (IQN), -a valid LUN number, the filesystem type, and the `PersistentVolume` API. + +You can verify that the storage exists in the underlying infrastructure before mounting it as a volume in {product-title}. All that is required for the iSCSI is the iSCSI target portal, a valid iSCSI Qualified Name (IQN), a valid LUN number, the filesystem type, and the `PersistentVolume` API. + +.Procedure + +* Verify that the storage exists in the underlying infrastructure before mounting it as a volume in {product-title} by creating the following .`PersistentVolume` object definition: .`PersistentVolume` object definition [source,yaml] diff --git a/modules/storage-persistent-storage-iscsi-volume-security.adoc b/modules/storage-persistent-storage-iscsi-volume-security.adoc index 7be786f96878..ea18af37f74f 100644 --- a/modules/storage-persistent-storage-iscsi-volume-security.adoc +++ b/modules/storage-persistent-storage-iscsi-volume-security.adoc @@ -2,6 +2,7 @@ // // * storage/persistent_storage-iscsi.adoc +:_mod-docs-content-type: REFERENCE [id="volume-security-iscsi_{context}"] = iSCSI volume security Users request storage with a `PersistentVolumeClaim` object. This claim only diff --git a/modules/storage-persistent-storage-lifecycle.adoc b/modules/storage-persistent-storage-lifecycle.adoc index b2f7d6b6933f..1b1d7d899d50 100644 --- a/modules/storage-persistent-storage-lifecycle.adoc +++ b/modules/storage-persistent-storage-lifecycle.adoc @@ -3,7 +3,7 @@ // * storage/understanding-persistent-storage.adoc //* microshift_storage/understanding-persistent-storage-microshift.adoc - +:_mod-docs-content-type: CONCEPT [id=lifecycle-volume-claim_{context}] = Lifecycle of a volume and claim diff --git a/modules/storage-persistent-storage-nfs-additional-configuration.adoc b/modules/storage-persistent-storage-nfs-additional-configuration.adoc index 12d27693f2df..07c1f7ca4b52 100644 --- a/modules/storage-persistent-storage-nfs-additional-configuration.adoc +++ b/modules/storage-persistent-storage-nfs-additional-configuration.adoc @@ -2,6 +2,8 @@ // // * storage/persistent_storage/persistent-storage-nfs.adoc +:_mod-docs-content-type: REFERENCE +[id="additional-config-troubleshooting_{context}"] = Additional configuration and troubleshooting Depending on what version of NFS is being used and how it is configured, diff --git a/modules/storage-persistent-storage-nfs-enforcing-disk-quota.adoc b/modules/storage-persistent-storage-nfs-enforcing-disk-quota.adoc index ab39560abc6c..4698772c71bc 100644 --- a/modules/storage-persistent-storage-nfs-enforcing-disk-quota.adoc +++ b/modules/storage-persistent-storage-nfs-enforcing-disk-quota.adoc @@ -2,8 +2,9 @@ // // * storage/persistent_storage/persistent-storage-nfs.adoc +:_mod-docs-content-type: CONCEPT [id="nfs-enforcing-disk-quota_{context}"] -= Enforcing disk quotas += Enforce disk quotas You can use disk partitions to enforce disk quotas and size constraints. Each partition can be its own export. Each export is one PV. diff --git a/modules/storage-persistent-storage-nfs-reclaiming-resources.adoc b/modules/storage-persistent-storage-nfs-reclaiming-resources.adoc index 34cb6a5a4884..32f0b809dc7d 100644 --- a/modules/storage-persistent-storage-nfs-reclaiming-resources.adoc +++ b/modules/storage-persistent-storage-nfs-reclaiming-resources.adoc @@ -2,6 +2,7 @@ // // * storage/persistent_storage/persistent-storage-nfs.adoc +:_mod-docs-content-type: REFERENCE [id="nfs-reclaiming-resources_{context}"] = Reclaiming resources NFS implements the {product-title} `Recyclable` plugin interface. Automatic diff --git a/modules/storage-persistent-storage-nfs-user-ids.adoc b/modules/storage-persistent-storage-nfs-user-ids.adoc index c3063bfb5215..cafb4007e4d3 100644 --- a/modules/storage-persistent-storage-nfs-user-ids.adoc +++ b/modules/storage-persistent-storage-nfs-user-ids.adoc @@ -2,6 +2,7 @@ // // * storage/persistent_storage/persistent-storage-nfs.aodc +:_mod-docs-content-type: REFERENCE [id="nfs-user-id_{context}"] = User IDs diff --git a/modules/storage-persistent-storage-nfs-volume-security.adoc b/modules/storage-persistent-storage-nfs-volume-security.adoc index 1463273802d4..87e4919b21ea 100644 --- a/modules/storage-persistent-storage-nfs-volume-security.adoc +++ b/modules/storage-persistent-storage-nfs-volume-security.adoc @@ -2,23 +2,18 @@ // // * storage/persistent_storage/persistent-storage-nfs.adoc +:_mod-docs-content-type: REFERENCE [id="nfs-volume-security_{context}"] = NFS volume security -This section covers NFS volume security, including matching permissions and -SELinux considerations. The user is expected to understand the basics of -POSIX permissions, process UIDs, supplemental groups, and SELinux. +This section covers NFS volume security, including matching permissions and SELinux considerations. The user is expected to understand the basics of POSIX permissions, process UIDs, supplemental groups, and SELinux. -Developers request NFS storage by referencing either a PVC by name or the -NFS volume plugin directly in the `volumes` section of their `Pod` +Developers request NFS storage by referencing either a PVC by name or the NFS volume plugin directly in the `volumes` section of their `Pod` definition. -The `/etc/exports` file on the NFS server contains the accessible NFS -directories. The target NFS directory has POSIX owner and group IDs. The -{product-title} NFS plugin mounts the container's NFS directory with the -same POSIX ownership and permissions found on the exported NFS directory. -However, the container is not run with its effective UID equal to the -owner of the NFS mount, which is the desired behavior. +The `/etc/exports` file on the NFS server contains the accessible NFS directories. The target NFS directory has POSIX owner and group IDs. The +{product-title} NFS plugin mounts the container's NFS directory with the same POSIX ownership and permissions found on the exported NFS directory. +However, the container is not run with its effective UID equal to the owner of the NFS mount, which is the desired behavior. As an example, if the target NFS directory appears on the NFS server as: @@ -43,13 +38,10 @@ $ id nfsnobody uid=65534(nfsnobody) gid=65534(nfsnobody) groups=65534(nfsnobody) ---- -Then the container must match SELinux labels, and either run with a UID of -`65534`, the `nfsnobody` owner, or with `5555` in its supplemental groups to access the directory. +Then the container must match SELinux labels, and either run with a UID of `65534`, the `nfsnobody` owner, or with `5555` in its supplemental groups to access the directory. [NOTE] ==== -The owner ID of `65534` is used as an example. Even though NFS's -`root_squash` maps `root`, uid `0`, to `nfsnobody`, uid `65534`, NFS -exports can have arbitrary owner IDs. Owner `65534` is not required -for NFS exports. +The owner ID of `65534` is used as an example. Even though NFS's `root_squash` maps `root`, uid `0`, to `nfsnobody`, uid `65534`, NFS +exports can have arbitrary owner IDs. Owner `65534` is not required for NFS exports. ==== diff --git a/modules/storage-persistent-storage-pv.adoc b/modules/storage-persistent-storage-pv.adoc index 351def867386..a3b4bd30292c 100644 --- a/modules/storage-persistent-storage-pv.adoc +++ b/modules/storage-persistent-storage-pv.adoc @@ -3,6 +3,7 @@ // * storage/understanding-persistent-storage.adoc //* microshift_storage/understanding-persistent-storage-microshift.adoc +:_mod-docs-content-type: REFERENCE [id="persistent-volumes_{context}"] = Persistent volumes diff --git a/modules/storage-persistent-storage-reclaim.adoc b/modules/storage-persistent-storage-reclaim.adoc index 07ac3f5b3dac..53e8b3d84569 100644 --- a/modules/storage-persistent-storage-reclaim.adoc +++ b/modules/storage-persistent-storage-reclaim.adoc @@ -3,11 +3,14 @@ // * storage/understanding-persistent-storage.adoc //* microshift_storage/understanding-persistent-storage-microshift.adoc - +:_mod-docs-content-type: PROCEDURE [id="reclaim-policy_{context}"] = Changing the reclaim policy of a persistent volume -To change the reclaim policy of a persistent volume: +You can change the reclaim policy of a persistent volume. + + +.Procedure . List the persistent volumes in your cluster: + @@ -32,7 +35,6 @@ NAME CAPACITY ACCESSMODES RECLAIMPOLIC $ oc patch pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' ---- -+ . Verify that your chosen persistent volume has the right policy: + [source,terminal] diff --git a/modules/storage-persistent-storage-volume-format.adoc b/modules/storage-persistent-storage-volume-format.adoc index 4d6555921e51..6e1a370f752c 100644 --- a/modules/storage-persistent-storage-volume-format.adoc +++ b/modules/storage-persistent-storage-volume-format.adoc @@ -8,16 +8,13 @@ // * storage/persistent_storage-aws.adoc // * storage/persistent_storage-gce.adoc +:_mod-docs-content-type: CONCEPT [id="volume-format-{provider}_{context}"] = Volume format -Before {product-title} mounts the volume and passes it to a container, it -checks that the volume contains a file system as specified by the `fsType` -parameter in the persistent volume definition. If the device is not -formatted with the file system, all data from the device is erased and the -device is automatically formatted with the given file system. -This verification enables you to use unformatted {provider} volumes as persistent volumes, -because {product-title} formats them before the first use. +Before {product-title} mounts the volume and passes it to a container, it checks that the volume contains a file system as specified by the `fsType` arameter in the persistent volume definition. If the device is not formatted with the file system, all data from the device is erased and the device is automatically formatted with the given file system. + +This verification enables you to use unformatted {provider} volumes as persistent volumes, because {product-title} formats them before the first use. // Undefined {provider} attribute, so that any mistakes are easily spotted :!provider: diff --git a/modules/strategies-for-s2i-troubleshooting.adoc b/modules/strategies-for-s2i-troubleshooting.adoc index c98a4da41abe..12e9671fe486 100644 --- a/modules/strategies-for-s2i-troubleshooting.adoc +++ b/modules/strategies-for-s2i-troubleshooting.adoc @@ -2,21 +2,26 @@ // // * support/troubleshooting/troubleshooting-s2i.adoc +:_mod-docs-content-type: PROCEDURE [id="strategies-for-s2i-troubleshooting_{context}"] = Strategies for Source-to-Image troubleshooting Use Source-to-Image (S2I) to build reproducible, Docker-formatted container images. You can create ready-to-run images by injecting application source code into a container image and assembling a new image. The new image incorporates the base image (the builder) and built source. -To determine where in the S2I process a failure occurs, you can observe the state of the pods relating to each of the following S2I stages: - -. *During the build configuration stage*, a build pod is used to create an application container image from a base image and application source code. - -. *During the deployment configuration stage*, a deployment pod is used to deploy application pods from the application container image that was built in the build configuration stage. The deployment pod also deploys other resources such as services and routes. The deployment configuration begins after the build configuration succeeds. - -. *After the deployment pod has started the application pods*, application failures can occur within the running application pods. For instance, an application might not behave as expected even though the application pods are in a `Running` state. In this scenario, you can access running application pods to investigate application failures within a pod. - -When troubleshooting S2I issues, follow this strategy: - -. Monitor build, deployment, and application pod status -. Determine the stage of the S2I process where the problem occurred -. Review logs corresponding to the failed stage +.Procedure + +. To determine where in the S2I process a failure occurs, you can observe the state of the pods relating to each of the following S2I stages: ++ +.. *During the build configuration stage*, a build pod is used to create an application container image from a base image and application source code. ++ +.. *During the deployment configuration stage*, a deployment pod is used to deploy application pods from the application container image that was built in the build configuration stage. The deployment pod also deploys other resources such as services and routes. The deployment configuration begins after the build configuration succeeds. ++ +.. *After the deployment pod has started the application pods*, application failures can occur within the running application pods. For instance, an application might not behave as expected even though the application pods are in a `Running` state. In this scenario, you can access running application pods to investigate application failures within a pod. + +. When troubleshooting S2I issues, follow this strategy: ++ +.. Monitor build, deployment, and application pod status. ++ +.. Determine the stage of the S2I process where the problem occurred. ++ +.. Review logs corresponding to the failed stage. diff --git a/modules/support-network-trace-methods.adoc b/modules/support-network-trace-methods.adoc index bce4d9761fb2..fac2497a322c 100644 --- a/modules/support-network-trace-methods.adoc +++ b/modules/support-network-trace-methods.adoc @@ -2,6 +2,7 @@ // // * support/gathering-cluster-data.adoc +:_mod-docs-content-type: REFERENCE [id="support-network-trace-methods_{context}"] = Network trace methods diff --git a/modules/support.adoc b/modules/support.adoc index e426587ad94a..402e9eb1389c 100644 --- a/modules/support.adoc +++ b/modules/support.adoc @@ -20,6 +20,7 @@ // * distr_tracing/distr_tracing_rn/distr-tracing-rn-3-0.adoc // * microshift_support/microshift-getting-support.adoc +:_mod-docs-content-type: REFERENCE [id="support_{context}"] = Getting support diff --git a/modules/templates-quickstart.adoc b/modules/templates-quickstart.adoc index b64a5baba861..513230c93c9b 100644 --- a/modules/templates-quickstart.adoc +++ b/modules/templates-quickstart.adoc @@ -2,6 +2,7 @@ // // * openshift_images/using-templates.adoc +:_mod-docs-content-type: CONCEPT [id="templates-quickstart_{context}"] = Quick start templates diff --git a/modules/templates-using-the-cli.adoc b/modules/templates-using-the-cli.adoc index 958011aa798c..8c10d95f1c5c 100644 --- a/modules/templates-using-the-cli.adoc +++ b/modules/templates-using-the-cli.adoc @@ -2,6 +2,7 @@ // // * openshift_images/using-templates.adoc +:_mod-docs-content-type: CONCEPT [id="templates-using-the-cli_{context}"] = Creating objects from templates by using the CLI diff --git a/modules/templates-waiting-for-readiness.adoc b/modules/templates-waiting-for-readiness.adoc index 6aa79a775887..47539b37d4bd 100644 --- a/modules/templates-waiting-for-readiness.adoc +++ b/modules/templates-waiting-for-readiness.adoc @@ -2,22 +2,33 @@ // // * openshift_images/using-templates.adoc +:_mod-docs-content-type: PROCEDURE [id="templates-waiting-for-readiness_{context}"] = Waiting for template readiness Template authors can indicate that certain objects within a template should be waited for before a template instantiation by the service catalog, {tsb-name}, or `TemplateInstance` API is considered complete. -To use this feature, mark one or more objects of kind `Build`, `BuildConfig`, `Deployment`, `DeploymentConfig`, `Job`, or `StatefulSet` in a template with the following annotation: +Before starting the procedure, read the following considerations: +* Set memory, CPU, and storage default sizes to make sure your application is given enough resources to run smoothly. + +* Avoid referencing the `latest` tag from images if that tag is used across major versions. This can cause running applications to break when new images are pushed to that tag. + +* A good template builds and deploys cleanly without requiring modifications after the template is deployed. + +.Procedure + +* To use the template feature, mark one or more objects of kind `Build`, `BuildConfig`, `Deployment`, `DeploymentConfig`, `Job`, or `StatefulSet` in a template with the following annotation: ++ [source,text] ---- "template.alpha.openshift.io/wait-for-ready": "true" ---- - ++ Template instantiation is not complete until all objects marked with the annotation report ready. Similarly, if any of the annotated objects report failed, or if the template fails to become ready within a fixed timeout of one hour, the template instantiation fails. - ++ For the purposes of instantiation, readiness and failure of each object kind are defined as follows: - ++ [cols="1a,2a,2a", options="header"] |=== @@ -50,9 +61,9 @@ For the purposes of instantiation, readiness and failure of each object kind are the object. | Not applicable. |=== - ++ The following is an example template extract, which uses the `wait-for-ready` annotation. Further examples can be found in the {product-title} quick start templates. - ++ [source,yaml] ---- kind: Template @@ -86,10 +97,3 @@ objects: ... ---- -.Additional recommendations - -* Set memory, CPU, and storage default sizes to make sure your application is given enough resources to run smoothly. - -* Avoid referencing the `latest` tag from images if that tag is used across major versions. This can cause running applications to break when new images are pushed to that tag. - -* A good template builds and deploys cleanly without requiring modifications after the template is deployed. diff --git a/modules/templates-writing-description.adoc b/modules/templates-writing-description.adoc index 5c7b243d1f94..6981fca38d08 100644 --- a/modules/templates-writing-description.adoc +++ b/modules/templates-writing-description.adoc @@ -2,6 +2,7 @@ // // * openshift_images/using-templates.adoc +:_mod-docs-content-type: REFERENCE [id="templates-writing-description_{context}"] = Writing the template description diff --git a/modules/templates-writing-labels.adoc b/modules/templates-writing-labels.adoc index f12d91bfb195..e49ae5322449 100644 --- a/modules/templates-writing-labels.adoc +++ b/modules/templates-writing-labels.adoc @@ -2,6 +2,7 @@ // // * openshift_images/using-templates.adoc +:_mod-docs-content-type: REFERENCE [id="templates-writing-labels_{context}"] = Writing template labels diff --git a/modules/templates-writing-object-list.adoc b/modules/templates-writing-object-list.adoc index 2dccee4a6548..691eed655c38 100644 --- a/modules/templates-writing-object-list.adoc +++ b/modules/templates-writing-object-list.adoc @@ -2,6 +2,7 @@ // // * openshift_images/using-templates.adoc +:_mod-docs-content-type: REFERENCE [id="templates-writing-object-list_{context}"] = Writing the template object list diff --git a/modules/templates-writing-parameters.adoc b/modules/templates-writing-parameters.adoc index 156e46663368..e59130d5f639 100644 --- a/modules/templates-writing-parameters.adoc +++ b/modules/templates-writing-parameters.adoc @@ -2,6 +2,7 @@ // // * openshift_images/using-templates.adoc +:_mod-docs-content-type: CONCEPT [id="templates-writing-parameters_{context}"] = Writing template parameters diff --git a/modules/templates-writing.adoc b/modules/templates-writing.adoc index 583eaf5c8450..f6ae2b531d4b 100644 --- a/modules/templates-writing.adoc +++ b/modules/templates-writing.adoc @@ -2,6 +2,7 @@ // // * openshift_images/using-templates.adoc +:_mod-docs-content-type: REFERENCE [id="templates-writing_{context}"] = Writing templates diff --git a/modules/threescale-backend-cache.adoc b/modules/threescale-backend-cache.adoc index efd9ce82f213..3041f3d3a133 100644 --- a/modules/threescale-backend-cache.adoc +++ b/modules/threescale-backend-cache.adoc @@ -3,6 +3,7 @@ // * service_mesh/v1x/threescale_adapter/threescale-adapter.adoc // * service_mesh/v2x/threescale_adapter/threescale-adapter.adoc +:_mod-docs-content-type: CONCEPT [id="threescale-backend-cache_{context}"] = 3scale backend cache diff --git a/modules/threescale-istio-adapter-apicast.adoc b/modules/threescale-istio-adapter-apicast.adoc index 75852d1a912a..1627379f8286 100644 --- a/modules/threescale-istio-adapter-apicast.adoc +++ b/modules/threescale-istio-adapter-apicast.adoc @@ -3,6 +3,7 @@ // * service_mesh/v1x/threescale_adapter/threescale-adapter.adoc // * service_mesh/v2x/threescale_adapter/threescale-adapter.adoc +:_mod-docs-content-type: CONCEPT [id="threescale-istio-adapter-apicast_{context}"] = 3scale Istio Adapter APIcast emulation diff --git a/modules/topology-manager-policies.adoc b/modules/topology-manager-policies.adoc index f2788306dc7c..3e021c40194b 100644 --- a/modules/topology-manager-policies.adoc +++ b/modules/topology-manager-policies.adoc @@ -3,6 +3,7 @@ // * scaling_and_performance/using-topology-manager.adoc // * post_installation_configuration/node-tasks.adoc +:_mod-docs-content-type: REFERENCE [id="topology-manager-policies_{context}"] = Topology Manager policies diff --git a/modules/troubleshooting-disabling-autoreboot-mco.adoc b/modules/troubleshooting-disabling-autoreboot-mco.adoc index 031d52ec2b62..1a48e26c321b 100644 --- a/modules/troubleshooting-disabling-autoreboot-mco.adoc +++ b/modules/troubleshooting-disabling-autoreboot-mco.adoc @@ -2,6 +2,7 @@ // // * support/troubleshooting/troubleshooting-operator-issues.adoc +:_mod-docs-content-type: CONCEPT [id="troubleshooting-disabling-autoreboot-mco_{context}"] = Disabling the Machine Config Operator from automatically rebooting diff --git a/modules/understanding-update-channels.adoc b/modules/understanding-update-channels.adoc index d3c5f8dca799..596932c4323e 100644 --- a/modules/understanding-update-channels.adoc +++ b/modules/understanding-update-channels.adoc @@ -3,8 +3,8 @@ // * updating/understanding_updates/understanding-update-channels-release.adoc +:_mod-docs-content-type: REFERENCE [id="understanding-update-channels_{context}"] - = Update channels ifndef::openshift-origin[] diff --git a/modules/unmanaged-operators.adoc b/modules/unmanaged-operators.adoc index 673db4424cc9..e00d174a52c6 100644 --- a/modules/unmanaged-operators.adoc +++ b/modules/unmanaged-operators.adoc @@ -4,6 +4,7 @@ // * updating/updating-cluster-within-minor.adoc // * observability/logging/cluster-logging-support.adoc +:_mod-docs-content-type: REFERENCE [id="unmanaged-operators_{context}"] = Support policy for unmanaged Operators diff --git a/modules/update-preparing-evaluate-alerts.adoc b/modules/update-preparing-evaluate-alerts.adoc index 164d04d2c226..164794fc98bd 100644 --- a/modules/update-preparing-evaluate-alerts.adoc +++ b/modules/update-preparing-evaluate-alerts.adoc @@ -2,6 +2,7 @@ // // * updating/preparing_for_updates/updating-cluster-prepare.adoc +:_mod-docs-content-type: PROCEDURE [id="update-preparing-evaluate-alerts_{context}"] = Reviewing alerts to identify uses of removed APIs @@ -10,6 +11,10 @@ Two alerts fire when an API is in use that will be removed in the next release: * `APIRemovedInNextReleaseInUse` - for APIs that will be removed in the next {product-title} release. * `APIRemovedInNextEUSReleaseInUse` - for APIs that will be removed in the next {product-title} Extended Update Support (EUS) release. -If either of these alerts are firing in your cluster, review the alerts and take action to clear the alerts by migrating manifests and API clients to use the new API version. +.Procedure -Use the `APIRequestCount` API to get more information about which APIs are in use and which workloads are using removed APIs, because the alerts do not provide this information. Additionally, some APIs might not trigger these alerts but are still captured by `APIRequestCount`. The alerts are tuned to be less sensitive to avoid alerting fatigue in production systems. +* If either of the alerts are firing in your cluster, review the alerts and take action to clear the alerts by migrating manifests and API clients to use the new API version. + +.Verification + +* Use the `APIRequestCount` API to get more information about which APIs are in use and which workloads are using removed APIs, because the alerts do not provide this information. Additionally, some APIs might not trigger these alerts but are still captured by `APIRequestCount`. The alerts are tuned to be less sensitive to avoid alerting fatigue in production systems. diff --git a/modules/update-preparing-list.adoc b/modules/update-preparing-list.adoc index 5ea2e7a137a8..4350989f0376 100644 --- a/modules/update-preparing-list.adoc +++ b/modules/update-preparing-list.adoc @@ -2,6 +2,7 @@ // // * updating/preparing_for_updates/updating-cluster-prepare.adoc +:_mod-docs-content-type: REFERENCE [id="update-preparing-list_{context}"] = Removed Kubernetes APIs diff --git a/modules/update-preparing-migrate.adoc b/modules/update-preparing-migrate.adoc index e3242cdd9016..ff6b28d97ac7 100644 --- a/modules/update-preparing-migrate.adoc +++ b/modules/update-preparing-migrate.adoc @@ -2,6 +2,7 @@ // // * updating/preparing_for_updates/updating-cluster-prepare.adoc +:_mod-docs-content-type: REFERENCE [id="update-preparing-migrate_{context}"] = Migrating instances of removed APIs diff --git a/modules/upi-installation-considerations.adoc b/modules/upi-installation-considerations.adoc index d28dee4bce5f..a010ef78662d 100644 --- a/modules/upi-installation-considerations.adoc +++ b/modules/upi-installation-considerations.adoc @@ -2,6 +2,7 @@ // // * support/troubleshooting/troubleshooting-installations.adoc +:_mod-docs-content-type: CONCEPT [id="upi-installation-considerations_{context}"] = User-provisioned infrastructure installation considerations diff --git a/modules/virt-loki-log-queries.adoc b/modules/virt-loki-log-queries.adoc index 1b6a008e62ec..e18b78e48c9e 100644 --- a/modules/virt-loki-log-queries.adoc +++ b/modules/virt-loki-log-queries.adoc @@ -2,7 +2,6 @@ // // * virt/support/virt-troubleshooting.adoc -:_mod-docs-content-type: reference [id="virt-loki-log-queries_{context}"] = {VirtProductName} LogQL queries diff --git a/modules/web-console-configuration.adoc b/modules/web-console-configuration.adoc index dde908f024db..6e6f4230c7ee 100644 --- a/modules/web-console-configuration.adoc +++ b/modules/web-console-configuration.adoc @@ -2,6 +2,7 @@ // // * web_console/configuring-web-console.adoc +:_mod-docs-content-type: PROCEDURE [id="web-console-configuration_{context}"] = Configuring the web console diff --git a/modules/web-console-disable.adoc b/modules/web-console-disable.adoc index ac20b55fbba5..35b656811221 100644 --- a/modules/web-console-disable.adoc +++ b/modules/web-console-disable.adoc @@ -2,6 +2,7 @@ // // * web_console/disabling-web-console.adoc +:_mod-docs-content-type: PROCEDURE [id="web-console-disable_{context}"] = Disabling the web console diff --git a/modules/what-huge-pages-do.adoc b/modules/what-huge-pages-do.adoc index 856b7eef0494..ef6501682b52 100644 --- a/modules/what-huge-pages-do.adoc +++ b/modules/what-huge-pages-do.adoc @@ -12,6 +12,7 @@ ifeval::["{context}" == "virt-using-huge-pages-with-vms"] :virt-hugepages: endif::[] +:_mod-docs-content-type: CONCEPT [id="what-huge-pages-do_{context}"] = What huge pages do diff --git a/modules/windows-machineset-aws.adoc b/modules/windows-machineset-aws.adoc index ac6a43cd5d99..ffa4fda99f3c 100644 --- a/modules/windows-machineset-aws.adoc +++ b/modules/windows-machineset-aws.adoc @@ -2,6 +2,7 @@ // // * windows_containers/creating_windows_machinesets/creating-windows-machineset-aws.adoc +:_mod-docs-content-type: REFERENCE [id="windows-machineset-aws_{context}"] = Sample YAML for a Windows MachineSet object on AWS diff --git a/modules/windows-machineset-azure.adoc b/modules/windows-machineset-azure.adoc index 6041086c5c31..9bcc7cf747f1 100644 --- a/modules/windows-machineset-azure.adoc +++ b/modules/windows-machineset-azure.adoc @@ -2,6 +2,7 @@ // // * windows_containers/creating_windows_machinesets/creating-windows-machineset-azure.adoc +:_mod-docs-content-type: REFERENCE [id="windows-machineset-azure_{context}"] = Sample YAML for a Windows MachineSet object on Azure diff --git a/modules/windows-machineset-gcp.adoc b/modules/windows-machineset-gcp.adoc index 4cfb54666050..ad15247ba647 100644 --- a/modules/windows-machineset-gcp.adoc +++ b/modules/windows-machineset-gcp.adoc @@ -2,6 +2,7 @@ // // * windows_containers/creating_windows_machinesets/creating-windows-machineset-gcp.adoc +:_mod-docs-content-type: REFERENCE [id="windows-machineset-gcp_{context}"] = Sample YAML for a Windows MachineSet object on {gcp-short} diff --git a/modules/windows-machineset-nutanix.adoc b/modules/windows-machineset-nutanix.adoc index 8f3f24d80a27..1cebad513d51 100644 --- a/modules/windows-machineset-nutanix.adoc +++ b/modules/windows-machineset-nutanix.adoc @@ -2,6 +2,7 @@ // // * windows_containers/creating_windows_machinesets/creating-windows-machineset-nutanix.adoc +:_mod-docs-content-type: REFERENCE [id="windows-machineset-nutanix_{context}"] = Sample YAML for a Windows MachineSet object on Nutanix diff --git a/modules/windows-machineset-vsphere.adoc b/modules/windows-machineset-vsphere.adoc index 8cd18030d96f..76d71d87bf19 100644 --- a/modules/windows-machineset-vsphere.adoc +++ b/modules/windows-machineset-vsphere.adoc @@ -2,6 +2,7 @@ // // * windows_containers/creating_windows_machinesets/creating-windows-machineset-vsphere.adoc +:_mod-docs-content-type: REFERENCE [id="windows-machineset-vsphere_{context}"] = Sample YAML for a Windows MachineSet object on vSphere diff --git a/modules/windows-node-services.adoc b/modules/windows-node-services.adoc index faf1bf5ca919..80645ccc7c29 100644 --- a/modules/windows-node-services.adoc +++ b/modules/windows-node-services.adoc @@ -2,6 +2,7 @@ // // * windows_containers/understanding-windows-container-workloads.adoc +:_mod-docs-content-type: REFERENCE [id="windows-node-services_{context}"] = Windows node services diff --git a/modules/windows-pod-placement.adoc b/modules/windows-pod-placement.adoc index 86b975a05280..871e808d6784 100644 --- a/modules/windows-pod-placement.adoc +++ b/modules/windows-pod-placement.adoc @@ -2,6 +2,7 @@ // // * windows_containers/scheduling-windows-workloads.adoc +:_mod-docs-content-type: CONCEPT [id="windows-pod-placement_{context}"] = Windows pod placement diff --git a/modules/windows-workload-management.adoc b/modules/windows-workload-management.adoc index fb2da5a94b1e..2f931e78be1b 100644 --- a/modules/windows-workload-management.adoc +++ b/modules/windows-workload-management.adoc @@ -2,6 +2,7 @@ // // * windows_containers/understanding-windows-container-workloads.adoc +:_mod-docs-content-type: CONCEPT [id="windows-workload-management_{context}"] = Windows workload management diff --git a/modules/wmco-does-not-install.adoc b/modules/wmco-does-not-install.adoc index a1a4c01efe08..a33cd90af99a 100644 --- a/modules/wmco-does-not-install.adoc +++ b/modules/wmco-does-not-install.adoc @@ -2,6 +2,7 @@ // // * support/troubleshooting/troubleshooting-windows-container-workload-issues.adoc +:_mod-docs-content-type: CONCEPT [id="wmco-does-not-install_{context}"] = Windows Machine Config Operator does not install diff --git a/modules/wmco-supported-csi-drivers.adoc b/modules/wmco-supported-csi-drivers.adoc index bf1e172748ce..58c6d4ba30e6 100644 --- a/modules/wmco-supported-csi-drivers.adoc +++ b/modules/wmco-supported-csi-drivers.adoc @@ -2,6 +2,7 @@ // // * windows_containers/scheduling-windows-workloads.adoc +:_mod-docs-content-type: CONCEPT [id="wmco-supported-csi-drivers_{context}"] = Support for Windows CSI drivers diff --git a/modules/wmco-upgrades.adoc b/modules/wmco-upgrades.adoc index 7dbcba1d03a3..62e8dfb066b3 100644 --- a/modules/wmco-upgrades.adoc +++ b/modules/wmco-upgrades.adoc @@ -2,6 +2,7 @@ // // * windows_containers/windows-node-upgrades.adoc +:_mod-docs-content-type: CONCEPT [id="wmco-upgrades_{context}"] = Windows Machine Config Operator upgrades diff --git a/snippets/technology-preview.adoc b/snippets/technology-preview.adoc index 96dda155de8c..713f12719104 100644 --- a/snippets/technology-preview.adoc +++ b/snippets/technology-preview.adoc @@ -3,6 +3,8 @@ // When including this file, ensure that {FeatureName} is set immediately before // the include. Otherwise it will result in an incorrect replacement. +:_mod-docs-content-type: SNIPPET + [IMPORTANT] ==== [subs="attributes+"]