diff --git a/images/logsv2-ui.png b/images/logsv2-ui.png index 6d8dc5d49..38c8b4876 100644 Binary files a/images/logsv2-ui.png and b/images/logsv2-ui.png differ diff --git a/modules/operator-upgrade.adoc b/modules/operator-upgrade.adoc index 93d3dbcb6..650321279 100644 --- a/modules/operator-upgrade.adoc +++ b/modules/operator-upgrade.adoc @@ -52,6 +52,7 @@ To update {productname} from one minor version to the next, for example, 3.10 -> For `z` stream upgrades, for example, 3.10.1 -> 3.10.2, updates are released in the major-minor channel that the user initially selected during install. The procedure to perform a `z` stream upgrade depends on the `approvalStrategy` as outlined above. If the approval strategy is set to `Automatic`, the {productname} Operator upgrades automatically to the newest `z` stream. This results in automatic, rolling {productname} updates to newer `z` streams with little to no downtime. Otherwise, the update must be manually approved before installation can begin. +//// [id="config-editor-removal"] == Removing config editor objects on {productname} Operator @@ -179,7 +180,6 @@ quayregistry-quay-config-editor-c866f64c4-68gtb 1/1 Running 0 $ oc delete pod quayregistry-quay-app-6bc4fbd456-8bc9c ---- -//// [id="upgrading-postgresql-databases"] === Updating {productname} from 3.8 -> 3.9 @@ -279,7 +279,7 @@ spec: database: ... ---- -//// + [id="upgrading-with-tls-cert-key-pairs-without-san"] ==== Upgrading with custom SSL/TLS certificate/key pairs without Subject Alternative Names @@ -294,7 +294,6 @@ If possible, you should regenerate your SSL/TLS certificates with the correct ho The `GODEBUG=x509ignoreCN=0` flag enables the legacy behavior of treating the CommonName field on X.509 certificates as a hostname when no SANs are present. However, this workaround is not recommended, as it will not persist across a redeployment. -//// [id="configuring-clair-v4-upgrading-from-33-34-to-36"] ==== Configuring Clair v4 when upgrading from 3.3.z or 3.4.z to 3.6 using the {productname} Operator diff --git a/modules/proc_upgrade_standalone.adoc b/modules/proc_upgrade_standalone.adoc index 2df3857d0..766dd2f8d 100644 --- a/modules/proc_upgrade_standalone.adoc +++ b/modules/proc_upgrade_standalone.adoc @@ -36,9 +36,9 @@ This document describes the steps needed to perform each individual upgrade. Det * link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrade_to_3_10_z_from_3_7_z[Upgrade to 3.10.z from 3.7.z] * link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrade_to_3_9_z_from_3_8_z[Upgrade to 3.9.z from 3.8.z] +//// * link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrade_to_3_9_z_from_3_7_z[Upgrade to 3.9.z from 3.7.z] * link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrade_to_3_8_z_from_3_7_z[Upgrade to 3.8.z from 3.7.z] -//// * link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrade_to_3_7_z_from_3_6_z[Upgrade to 3.7.z from 3.6.z] * link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrade_to_3_7_z_from_3_5_z[Upgrade to 3.7.z from 3.5.z] * link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrade_to_3_7_z_from_3_4_z[Upgrade to 3.7.z from 3.4.z] @@ -67,11 +67,9 @@ The general procedure for a manual upgrade consists of the following steps: == Accessing images -Images for Quay 3.4.0 and later are available from link:https://registry.redhat.io[registry.redhat.io] and +{productname} image from version 3.4.0 and later are available from link:https://registry.redhat.io[registry.redhat.io] and link:https://registry.access.redhat.com[registry.access.redhat.com], with authentication set up as described in link:https://access.redhat.com/RegistryAuthentication[Red Hat Container Registry Authentication]. -Images for Quay 3.3.4 and earlier are available from link:https://quay.io[quay.io], with authentication set up as described in link:https://access.redhat.com/solutions/3533201[Accessing {productname} without a CoreOS login]. - == Upgrade to 3.11.z from 3.10.z === Target images @@ -138,6 +136,7 @@ endif::upstream[] * **PostgreSQL:** {postgresimage} * **Redis:** {redisimage} +//// == Upgrade to 3.9.z from 3.8.z If you are upgrading your standalone {productname} deployment from 3.8.z -> 3.9, it is highly recommended that you upgrade PostgreSQL from version 10 -> 13. To upgrade PostgreSQL from 10 -> 13, you must bring down your PostgreSQL 10 database and run a migration script to initiate the process. @@ -282,7 +281,6 @@ endif::upstream[] * **PostgreSQL:** {postgresimage} * **Redis:** {redisimage} -//// == Upgrade to 3.7.z from 3.6.z === Target images diff --git a/modules/rn_3_11_0.adoc b/modules/rn_3_11_0.adoc index f1c96938b..d91293dd6 100644 --- a/modules/rn_3_11_0.adoc +++ b/modules/rn_3_11_0.adoc @@ -7,7 +7,7 @@ The following sections detail _y_ and _z_ stream release information. [id="rn-3-11-0"] == RHBA-2024:1475 - {productname} 3.11.0 release -Issued 2024-03-28 +Issued 2024-04-02 {productname} release {producty} is now available with Clair {clairproductminv}. The bug fixes that are included in the update are listed in the link:https://access.redhat.com/errata/RHBA-2024:1475[RHBA-2024:1475] advisory. @@ -70,9 +70,10 @@ For more information, see link:https://access.redhat.com/documentation/en-us/red {productname} Builds are now supported when using the v2 UI. This feature must be enabled prior to building container images by setting `FEATURE_BUILD_SUPPORT: true` in your `config.yaml` file. -For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html-single/use_red_hat_quay/index#building-dockerfiles[Building container images]. +For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html-single/use_red_hat_quay/index#starting-a-build[Creating a new build]. + [id="auto-pruning-repositories-ui"] -==== Auto-pruning repositories UI +==== Auto-pruning repositories v2 UI {productname} 3.11 offers users the ability to create auto-pruning policies using the v2 UI. @@ -120,7 +121,7 @@ The following configuration fields have been added to {productname} {producty}. [id="aws-s3-sts-configuration-fields"] === Configuration fields for AWS S3 STS deployments -The following configuration fields have been added when configuring AWS STS for {productname}. These fields are included when configuring AWS S3 storage for your deployment. +The following configuration fields have been added when configuring AWS STS for {productname}. These fields are used when configuring AWS S3 storage for your deployment. * *.sts_role_arn*. The unique Amazon Resource Name (ARN) required when configuring AWS STS for {productname}. * *.sts_user_access_key*. The generated AWS S3 user access key required when configuring AWS STS for {productname}. @@ -158,11 +159,6 @@ This API endpoint can be used with `POST`, `GET`, and `DELETE` calls to create, The following sections note known issues and limitations for {productname} {producty}. -[id="dark-mode-ui-v2-known-issues"] -=== {productname} v2 UI dark mode known issue - -If you are using the the automatic mode selection, which chooses between light or dark modes depending on the user's browser preference, your operating system appearance is overridden by the browser website appearance setting. If you find that the device-based theme is not working as expect, check your browser appearance setting. This is a known issue and will be fixed in a future version of {productname}. (link:https://issues.redhat.com/browse/PROJQUAY-6903[*PROJQUAY-6903*]) - [id="oidc-team-sync-known-issues"] === {productname} OIDC team synchronization known issues @@ -180,13 +176,26 @@ For more information, see link:https://issues.redhat.com/browse/PROJQUAY-6754[*P [id="team-sync-removal-known-issue"] ==== Unable to sync change when OIDC user is removed from OIDC -Currently, when an OIDC user is removed from their OIDC provider, the user is not removed from the team on {productname}. Consequently, they are still have to use the robot account token and app token to push and pull images from the registry. The expected behavior is that, when removed from the OIDC group, they, and their related tokens, should be removed from the {productname}. This is a known issue and will be fixed in a future version of {productname}. (link:https://issues.redhat.com/browse/PROJQUAY-6842[*PROJQUAY-6842*]). +Currently, when an OIDC user is removed from their OIDC provider, the user is not removed from the team on {productname}. Consequently, they are still have to use the robot account token and app token to push and pull images from the registry. The expected behavior is that, when removed from the OIDC group, they, and their related tokens, should be removed from the {productname}. This is a known issue and will be fixed in a future version of {productname}. (link:https://issues.redhat.com/browse/PROJQUAY-6842[*PROJQUAY-6842*]) [id="entra-id-team-sync-known-issue"] ==== Object ID must be used when OIDC provider is Microsoft Entra ID When using Microsoft Entra ID as your OIDC provider, {productname} administrators must input the *Object ID* of the OIDC group instead of the group name. The v2 UI does not currently alert users that Microsoft Entra ID users must input the Object ID of the OIDC group. This is a known issue and will be fixed in a future version of {productname}. (link:https://issues.redhat.com/browse/PROJQUAY-6917[*PROJQUAY-6917*]) +[id="upgrading-38-311-limitation"] +=== Upgrading {productname-ocp} 3.8 directly to 3.11 limitation + +Upgrading {productname-ocp} from 3.8 to 3.11 does not work. Users must upgrade from {productname-ocp} from 3.8 to 3.9 or 3.10, and then proceed with the upgrade to 3.11. + +For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html-single/upgrade_red_hat_quay/index#upgrade_overview[Upgrade {productname}]. + +[id="configurable-resource-limitation"] +=== Configurable resource request limitation + +Attempting to set resource limitations for the `Quay` pod too low results in the pod being unable to boot up with the following statuses returned: `OOMKILLED` and `CrashLoopBackOff`. Resource limitations can not be set lower than the minimum requirement, which can be found on the link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html-single/deploying_the_red_hat_quay_operator_on_openshift_container_platform/index#configuring-resources-managed-components[Configuring resources for managed components on {ocp}] page. + + [id="v2-ui-known-issues-311"] === {productname} v2 UI known issues @@ -220,19 +229,13 @@ The {productname} team is aware of the following known issues on the v2 UI: * link:https://issues.redhat.com/browse/PROJQUAY-6767[*PROJQUAY-6767*]. The new UI can't download build logs * link:https://issues.redhat.com/browse/PROJQUAY-6758[*PROJQUAY-6758*]. The new UI should display correct operation number when hover over different operation type * link:https://issues.redhat.com/browse/PROJQUAY-6757[*PROJQUAY-6757*]. The new UI usage log should display the tag expiration time as date format -//* link:[**]. - -[id="upgrading-38-311-limitation"] -=== Upgrading {productname-ocp} 3.8 directly to 3.11 limitation - -Upgrading {productname-ocp} from 3.8 to 3.11 does not work. Users must upgrade from {productname-ocp} from 3.8 to 3.9 or 3.10, and then proceed with the upgrade to 3.11. -For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html-single/upgrade_red_hat_quay/index#upgrade_overview[Upgrade {productname}]. +[id="dark-mode-ui-v2-known-issues"] +==== {productname} v2 UI dark mode known issue -[id="configurable-resource-limitation"] -=== Configurable resource request limitation +If you are using the the automatic mode selection, which chooses between light or dark modes depending on the user's browser preference, your operating system appearance is overridden by the browser website appearance setting. If you find that the device-based theme is not working as expect, check your browser appearance setting. This is a known issue and will be fixed in a future version of {productname}. (link:https://issues.redhat.com/browse/PROJQUAY-6903[*PROJQUAY-6903*]) +//* link:[**]. -Attempting to set resource limitations for the `Quay` pod too low results in the pod being unable to boot up with the following statuses returned: `OOMKILLED` and `CrashLoopBackOff`. Resource limitations can not be set lower than the minimum requirement, which can be found on the link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html-single/deploying_the_red_hat_quay_operator_on_openshift_container_platform/index#configuring-resources-managed-components[Configuring resources for managed components on {ocp}] page. //// @@ -281,11 +284,13 @@ The following technical changes have been made to {productname} in 3.11. [id="removal-support-pgbouncer"] === Removal of support for PgBouncer -{productname} no longer supports PgBouncer. +{productname} 3.11 does not support PgBouncer. [id="bug-fixes-311"] == {productname} bug fixes +The following issues were fixed with {productname} 3.11: + * link:https://issues.redhat.com/browse/PROJQUAY-6586[*PROJQUAY-6586*]. Big layer upload fails on Ceph/RADOS driver. * link:https://issues.redhat.com/browse/PROJQUAY-6648[*PROJQUAY-6648*]. Application token Docker/Podman login command fails on windows. * link:https://issues.redhat.com/browse/PROJQUAY-6673[*PROJQUAY-6673*]. Apply IGNORE_UNKNOWN_MEDIATYPE to child manifests in manifest lists.