diff --git a/.s2i/httpd-cfg/01-commercial.conf b/.s2i/httpd-cfg/01-commercial.conf index c04ae42d4dd2..f84cb9408da0 100644 --- a/.s2i/httpd-cfg/01-commercial.conf +++ b/.s2i/httpd-cfg/01-commercial.conf @@ -179,6 +179,9 @@ AddType text/vtt vtt RewriteRule ^container-platform/(4\.11|4\.12)/scalability_and_performance/cnf-performance-addon-operator-for-low-latency-nodes.html /container-platform/$1/scalability_and_performance/cnf-low-latency-tuning.html [NE,R=302] + # redirect for scalability and performance per Shane Lovern 7/19 + RewriteRule ^container-platform/4\.13/scalability_and_performance/sno-du-enabling-workload-partitioning-on-single-node-openshift.html /container-platform/4.13/scalability_and_performance/enabling-workload-partitioning.html [NE,R=302] + # CNV scenarios based redirect RewriteRule ^container-platform/4\.8/virt/learn_more_about_ov.html /container-platform/4.8/virt/virt-learn-more-about-openshift-virtualization.html [NE,R=301] diff --git a/.vale.ini b/.vale.ini index 7af1876715ce..3c1403e6c52c 100644 --- a/.vale.ini +++ b/.vale.ini @@ -2,7 +2,7 @@ StylesPath = .vale/styles MinAlertLevel = suggestion -Packages = RedHat, https://github.com/redhat-documentation/vale-at-red-hat/releases/latest/download/AsciiDoc.zip, https://github.com/redhat-documentation/vale-at-red-hat/releases/latest/download/OpenShiftAsciiDoc.zip +Packages = RedHat, AsciiDoc, OpenShiftAsciiDoc Vocab = OpenShiftDocs @@ -25,3 +25,4 @@ Vale.Avoid = YES OpenShiftAsciiDoc.ModuleContainsParentAssemblyComment = NO OpenShiftAsciiDoc.NoNestingInModules = NO OpenShiftAsciiDoc.NoXrefInModules = NO +OpenShiftAsciiDoc.IdHasContextVariable = NO diff --git a/_attributes/common-attributes.adoc b/_attributes/common-attributes.adoc index b3d4c4073856..0c2a5c5d5fe1 100644 --- a/_attributes/common-attributes.adoc +++ b/_attributes/common-attributes.adoc @@ -58,14 +58,6 @@ endif::openshift-origin[] :cert-manager-operator: cert-manager Operator for Red Hat OpenShift :secondary-scheduler-operator-full: Secondary Scheduler Operator for Red Hat OpenShift :secondary-scheduler-operator: Secondary Scheduler Operator -:rh-virtualization-first: Red Hat Virtualization (RHV) -:rh-virtualization: RHV -:rh-virtualization-engine-name: Manager -ifdef::openshift-origin[] -:rh-virtualization-first: oVirt -:rh-virtualization: oVirt -:rh-virtualization-engine-name: Engine -endif::[] // Backup and restore :velero-domain: velero.io :velero-version: 1.9 @@ -109,9 +101,17 @@ endif::[] :VirtVersion: 4.13 :KubeVirtVersion: v0.59.0 :HCOVersion: 4.13.0 +:CNVNamespace: openshift-cnv +:CNVOperatorDisplayName: OpenShift Virtualization Operator +:CNVSubscriptionSpecSource: redhat-operators +:CNVSubscriptionSpecName: kubevirt-hyperconverged :delete: image:delete.png[title="Delete"] ifdef::openshift-origin[] :VirtProductName: OKD Virtualization +:CNVNamespace: kubevirt-hyperconverged +:CNVOperatorDisplayName: KubeVirt HyperConverged Cluster Operator +:CNVSubscriptionSpecSource: community-operators +:CNVSubscriptionSpecName: community-kubevirt-hyperconverged endif::[] //distributed tracing :DTProductName: Red Hat OpenShift distributed tracing @@ -140,12 +140,15 @@ endif::[] :product-dedicated: Red Hat OpenShift Dedicated :SMProductName: Red Hat OpenShift Service Mesh :SMProductShortName: Service Mesh -:SMProductVersion: 2.4 +:SMProductVersion: 2.4.1 :MaistraVersion: 2.4 //Service Mesh v1 :SMProductVersion1x: 1.1.18.2 //Windows containers :productwinc: Red Hat OpenShift support for Windows Containers +// IBM Cloud +:ibmcloudBMProductName: IBM Cloud Bare Metal (Classic) +:ibmcloudBMRegProductName: IBM Cloud® Bare Metal (Classic) // IBM Power :ibmpowerProductName: IBM Power // IBM zSystems diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml index d3d70e687d68..9cd10df5c87a 100644 --- a/_topic_maps/_topic_map.yml +++ b/_topic_maps/_topic_map.yml @@ -38,4 +38,4 @@ Topics: - Name: Collecting debugging data for a support case File: collecting-debugging-data-for-support - Name: Troubleshooting issues in GitOps - File: troubleshooting-issues-in-GitOps \ No newline at end of file + File: troubleshooting-issues-in-GitOps diff --git a/gitops/gitops-release-notes.adoc b/gitops/gitops-release-notes.adoc index fa376967e7b4..bd4a0b3973cf 100644 --- a/gitops/gitops-release-notes.adoc +++ b/gitops/gitops-release-notes.adoc @@ -23,6 +23,7 @@ include::modules/go-compatibility-and-support-matrix.adoc[leveloffset=+1] include::modules/making-open-source-more-inclusive.adoc[leveloffset=+1] // Modules included, most to least recent +include::modules/gitops-release-notes-1-9-1.adoc[leveloffset=+1] include::modules/gitops-release-notes-1-9-0.adoc[leveloffset=+1] include::modules/gitops-release-notes-1-8-3.adoc[leveloffset=+1] diff --git a/modules/gitops-logging-into-keycloak.adoc b/modules/gitops-logging-into-keycloak.adoc index 255fe5dfa88a..a6e1d69fa243 100644 --- a/modules/gitops-logging-into-keycloak.adoc +++ b/modules/gitops-logging-into-keycloak.adoc @@ -35,7 +35,7 @@ keycloak-1-2sjcl 1/1 Running 0 45m ---- $ oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_USERNAME -SSO_ADMIN_USERNAME=Cqid54Ih +SSO_ADMIN_USERNAME= ---- .. Get the Keycloak password: + @@ -43,7 +43,7 @@ SSO_ADMIN_USERNAME=Cqid54Ih ---- $ oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_PASSWORD -SSO_ADMIN_PASSWORD=GVXxHifH +SSO_ADMIN_PASSWORD= ---- . On the login page, click *LOG IN VIA KEYCLOAK*. + @@ -66,6 +66,3 @@ Login using `kubeadmin` is not supported. policy.csv: , , role:admin ---- - - - diff --git a/modules/gitops-release-notes-1-9-0.adoc b/modules/gitops-release-notes-1-9-0.adoc index 9da27358304c..988380a884d1 100644 --- a/modules/gitops-release-notes-1-9-0.adoc +++ b/modules/gitops-release-notes-1-9-0.adoc @@ -10,13 +10,13 @@ [id="errata-updates-1-9-0_{context}"] == Errata updates -=== RHSA-2023:112944 - {gitops-title} 1.9.0 security update advisory +=== RHSA-2023:3557 - {gitops-title} 1.9.0 security update advisory Issued: 2023-06-09 The list of security fixes that are included in this release is documented in the following advisory: -* link:https://access.redhat.com/errata/RHSA-2023:112944[RHSA-2023:112944] +* link:https://access.redhat.com/errata/RHSA-2023:3557[RHSA-2023:3557] If you have installed the {gitops-title} Operator, run the following command to view the container images in this release: diff --git a/modules/gitops-release-notes-1-9-1.adoc b/modules/gitops-release-notes-1-9-1.adoc new file mode 100644 index 000000000000..cca0e6f9bff6 --- /dev/null +++ b/modules/gitops-release-notes-1-9-1.adoc @@ -0,0 +1,49 @@ +// Module included in the following assembly: +// +// * gitops/gitops-release-notes.adoc + +:_content-type: REFERENCE + +[id="gitops-release-notes-1-9-1_{context}"] += Release notes for {gitops-title} 1.9.1 + +{gitops-title} 1.9.1 is now available on {product-title} 4.12 and 4.13. + +[id="errata-updates-1-9-1_{context}"] +== Errata updates + +=== RHSA-2023:3591 and RHBA-2023:4117 - {gitops-title} 1.9.1 security update advisory + +Issued: 2023-07-17 + +The list of security fixes that are included in this release is documented in the following advisories: + +* link:https://access.redhat.com/errata/RHSA-2023:3591[RHSA-2023:3591] +* link:https://access.redhat.com/errata/RHBA-2023:4117[RHBA-2023:4117] + +If you have installed the {gitops-title} Operator, run the following command to view the container images in this release: + +[source,terminal] +---- +$ oc describe deployment gitops-operator-controller-manager -n openshift-operators +---- + +[id="new-features-1-9-1_{context}"] +== New features + +The current release adds the following improvements: + +* With this update, the bundled Argo CD has been updated to version 2.7.6. + +[id="fixed-issues-1-9-1_{context}"] +== Fixed issues + +The following issues have been resolved in the current release: + +* Before this update, Argo CD was becoming unresponsive when there was an increase in namespaces and applications. This update fixes the issue by removing a deadlock. Deadlock occurs when two functions are competing for resources. Now, you should not experience crashes or unresponsiveness when there is an increase in namespaces or applications. link:https://issues.redhat.com/browse/GITOPS-2782[GITOPS-2782] + +* Before this update, the Argo CD application controller resource could suddenly stop working when resynchronizing applications. This update fixes the issue by adding logic to prevent a cluster cache deadlock. Now, you should not experience the deadlock situation, and applications should resynchronize successfully. link:https://issues.redhat.com/browse/GITOPS-2880[GITOPS-2880] + +* Before this update, there was a mismatch in the RSA key for known hosts in the `argocd-ssh-known-hosts-cm` config map. This update fixes the issue by matching the RSA key with the upstream project. Now, you can use the default RSA keys on default deployments. link:https://issues.redhat.com/browse/GITOPS-3042[GITOPS-3042] + +* Before this update, the reconciliation timeout setting in the `argocd-cm` config map was not being correctly applied to the Argo CD application controller resource. This update fixes the issue by correctly reading and applying the reconciliation timeout setting from the `argocd-cm` config map. Now, you can modify the reconciliation timeout value from the `AppSync` setting without a problem. link:https://issues.redhat.com/browse/GITOPS-2810[GITOPS-2810] diff --git a/modules/virt-cluster-resource-requirements.adoc b/modules/virt-cluster-resource-requirements.adoc deleted file mode 100644 index 60cccdfdb63a..000000000000 --- a/modules/virt-cluster-resource-requirements.adoc +++ /dev/null @@ -1,90 +0,0 @@ -// Module included in the following assemblies: -// -// * virt/install/preparing-cluster-for-virt.adoc - -:_content-type: REFERENCE -[id="virt-cluster-resource-requirements_{context}"] -= Physical resource overhead requirements - -{VirtProductName} is an add-on to {product-title} and imposes additional overhead that you must account for when planning a cluster. Each cluster machine must accommodate the following overhead requirements in addition to the {product-title} requirements. Oversubscribing the physical resources in a cluster can affect performance. - -[IMPORTANT] -==== -The numbers noted in this documentation are based on Red Hat's test methodology and setup. These numbers can vary based on your own individual setup and environments. -==== - -[discrete] -[id="memory-overhead_{context}"] -== Memory overhead - -Calculate the memory overhead values for {VirtProductName} by using the equations below. - -.Cluster memory overhead - ----- -Memory overhead per infrastructure node ≈ 150 MiB ----- - ----- -Memory overhead per worker node ≈ 360 MiB ----- - -Additionally, {VirtProductName} environment resources require a total of 2179 MiB of RAM that is spread across all infrastructure nodes. - -.Virtual machine memory overhead - ----- -Memory overhead per virtual machine ≈ (1.002 * requested memory) + 146 MiB \ - + 8 MiB * (number of vCPUs) \ <1> - + 16 MiB * (number of graphics devices) <2> ----- -<1> Number of virtual CPUs requested by the virtual machine -<2> Number of virtual graphics cards requested by the virtual machine - -If your environment includes a Single Root I/O Virtualization (SR-IOV) network device or a Graphics Processing Unit (GPU), allocate 1 GiB additional memory overhead for each device. - -[discrete] -[id="CPU-overhead_{context}"] -== CPU overhead - -Calculate the cluster processor overhead requirements for {VirtProductName} by using the equation below. The CPU overhead per virtual machine depends on your individual setup. - -.Cluster CPU overhead - ----- -CPU overhead for infrastructure nodes ≈ 4 cores ----- - -{VirtProductName} increases the overall utilization of cluster level services such as logging, routing, and monitoring. To account for this workload, ensure that nodes that host infrastructure components have capacity allocated for 4 additional cores (4000 millicores) distributed across those nodes. - ----- -CPU overhead for worker nodes ≈ 2 cores + CPU overhead per virtual machine ----- - -Each worker node that hosts virtual machines must have capacity for 2 additional cores (2000 millicores) for {VirtProductName} management workloads in addition to the CPUs required for virtual machine workloads. - -.Virtual machine CPU overhead - -If dedicated CPUs are requested, there is a 1:1 impact on the cluster CPU overhead requirement. Otherwise, there are no specific rules about how many CPUs a virtual machine requires. - -[discrete] -[id="storage-overhead_{context}"] -== Storage overhead - -Use the guidelines below to estimate storage overhead requirements for your {VirtProductName} environment. - -.Cluster storage overhead - ----- -Aggregated storage overhead per node ≈ 10 GiB ----- - -10 GiB is the estimated on-disk storage impact for each node in the cluster when you install {VirtProductName}. - -.Virtual machine storage overhead - -Storage overhead per virtual machine depends on specific requests for resource allocation within the virtual machine. The request could be for ephemeral storage on the node or storage resources hosted elsewhere in the cluster. {VirtProductName} does not currently allocate any additional ephemeral storage for the running container itself. - -.Example - -As a cluster administrator, if you plan to host 10 virtual machines in the cluster, each with 1 GiB of RAM and 2 vCPUs, the memory impact across the cluster is 11.68 GiB. The estimated on-disk storage impact for each node in the cluster is 10 GiB and the CPU impact for worker nodes that host virtual machine workloads is a minimum of 2 cores. \ No newline at end of file diff --git a/scripts/ocpdocs/_previewpage b/scripts/ocpdocs/_previewpage index fea02fc97cb3..56725748434b 100644 --- a/scripts/ocpdocs/_previewpage +++ b/scripts/ocpdocs/_previewpage @@ -107,7 +107,7 @@ MicroShift diff --git a/snippets/technology-preview.adoc b/snippets/technology-preview.adoc index 2ebd7dde423b..9c1acea0a89b 100644 --- a/snippets/technology-preview.adoc +++ b/snippets/technology-preview.adoc @@ -4,12 +4,7 @@ [IMPORTANT] ==== [subs="attributes+"] -{FeatureName} is a Technology Preview feature only. Technology Preview features -are not supported with Red Hat production service level agreements (SLAs) and -might not be functionally complete. Red Hat does not recommend using them -in production. These features provide early access to upcoming product -features, enabling customers to test functionality and provide feedback during -the development process. +{FeatureName} is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see link:https://access.redhat.com/support/offerings/techpreview/[Technology Preview Features Support Scope]. ==== diff --git a/virt/install/preparing-cluster-for-virt.adoc b/virt/install/preparing-cluster-for-virt.adoc deleted file mode 100644 index 0d1b245f5b8b..000000000000 --- a/virt/install/preparing-cluster-for-virt.adoc +++ /dev/null @@ -1,100 +0,0 @@ -:_content-type: ASSEMBLY -include::_attributes/common-attributes.adoc[] -[id="preparing-cluster-for-virt"] -= Preparing your cluster for {VirtProductName} -:context: preparing-cluster-for-virt -:toclevels: 3 - -toc::[] - -Review this section before you install {VirtProductName} to ensure that your cluster meets the requirements. - -[IMPORTANT] -==== -You can use any installation method, including user-provisioned, installer-provisioned, or assisted installer, to deploy {product-title}. However, the installation method and the cluster topology might affect {VirtProductName} functionality, such as snapshots or live migration. -==== - -//// -.FIPS mode - -If you install your cluster in xref:../../installing/installing-fips.adoc#installing-fips-mode_installing-fips[FIPS mode], no additional setup is required for {VirtProductName}. -//// - -.IPv6 - -You cannot run {VirtProductName} on a single-stack IPv6 cluster. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2193267[*BZ#2193267*]) - -include::modules/virt-hardware-os-requirements.adoc[leveloffset=+1] - -* If your cluster uses worker nodes with different CPUs, live migration failures can occur because different CPUs have different capabilities. To avoid such failures, use CPUs with appropriate capacity for each node and set node affinity on your virtual machines to ensure successful migration. See xref:../../nodes/scheduling/nodes-scheduler-node-affinity.adoc#nodes-scheduler-node-affinity-configuring-required_nodes-scheduler-node-affinity[Configuring a required node affinity rule] for more information. - -[role="_additional-resources"] -.Additional resources - -* xref:../../architecture/architecture-rhcos.adoc#rhcos-about_architecture-rhcos[About RHCOS]. -* link:https://catalog.redhat.com[Red Hat Ecosystem Catalog] for supported CPUs. -* xref:../../storage/index.adoc#storage-overview[Supported storage]. - -include::modules/virt-cluster-resource-requirements.adoc[leveloffset=+1] - -include::modules/virt-about-storage-volumes-for-vm-disks.adoc[leveloffset=+1] - -[role="_additional-resources"] -.Additional resources - -* xref:../../storage/index.adoc#openshift-storage-common-terms_storage-overview[Glossary of common terms for {product-title} storage] - -[id="object-maximums_{context}"] -== Object maximums - -You must consider the following tested object maximums when planning your cluster: - -* xref:../../scalability_and_performance/planning-your-environment-according-to-object-maximums.html#planning-your-environment-according-to-object-maximums[{product-title} object maximums]. -* link:https://access.redhat.com/articles/6571671[{VirtProductName} object maximums]. - -[id="restricted-networks-environments_{context}"] -== Restricted network environments - -If you install {VirtProductName} in a restricted environment with no internet connectivity, you must xref:../../operators/admin/olm-restricted-networks.adoc#olm-restricted-networks[configure Operator Lifecycle Manager for restricted networks]. - -If you have limited internet connectivity, you can xref:../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[configure proxy support in Operator Lifecycle Manager] to access the Red Hat-provided OperatorHub. - -[id="live-migration_{context}"] -== Live migration - -Live migration has the following requirements: - -* Shared storage with `ReadWriteMany` (RWX) access mode. -* Sufficient RAM and network bandwidth. -* If the virtual machine uses a host model CPU, the nodes must support the virtual machine's host model CPU. - -// The HA section actually belongs to OpenShift, not Virt -[id="cluster-high-availability-options_{context}"] -== Cluster high-availability options - -You can configure one of the following high-availability (HA) options for your cluster: - -* Automatic high availability for xref:../../installing/installing_bare_metal_ipi/ipi-install-overview.adoc#ipi-install-overview[installer-provisioned infrastructure] (IPI) is available by deploying xref:../../machine_management/deploying-machine-health-checks.adoc#machine-health-checks-about_deploying-machine-health-checks[machine health checks]. -+ -[NOTE] -==== -In {product-title} clusters installed using installer-provisioned infrastructure and with MachineHealthCheck properly configured, if a node fails the MachineHealthCheck and becomes unavailable to the cluster, it is recycled. What happens next with VMs that ran on the failed node depends on a series of conditions. See xref:../../virt/virtual_machines/virt-create-vms.adoc#virt-about-runstrategies-vms_virt-create-vms[About RunStrategies for virtual machines] for more detailed information about the potential outcomes and how RunStrategies affect those outcomes. -==== - -* Automatic high availability for both IPI and non-IPI is available by using the *Node Health Check Operator* on the {product-title} cluster to deploy the `NodeHealthCheck` controller. The controller identifies unhealthy nodes and uses the Self Node Remediation Operator to remediate the unhealthy nodes. For more information on remediation, fencing, and maintaining nodes, see the link:https://access.redhat.com/documentation/en-us/workload_availability_for_red_hat_openshift/23.2/html-single/remediation_fencing_and_maintenance/index#about-remediation-fencing-maintenance[Workload Availability for Red Hat OpenShift] documentation. - -+ --- -ifdef::openshift-enterprise[] -:FeatureName: Node Health Check Operator -include::snippets/technology-preview.adoc[leveloffset=+2] -:!FeatureName: -endif::[] --- - -* High availability for any platform is available by using either a monitoring system or a qualified human to monitor node availability. When a node is lost, shut it down and run `oc delete node `. -+ -[NOTE] -==== -Without an external monitoring system or a qualified human monitoring node health, virtual machines lose high availability. -====