mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
Version number bumps for 4.6
This commit is contained in:
Ashley Hardin
@@ -9,7 +9,7 @@ You can upgrade metering to {product-version} by updating the Metering Operator
|
||||
|
||||
== Prerequisites
|
||||
|
||||
* The cluster is updated to 4.5.
|
||||
* The cluster is updated to 4.6.
|
||||
* The xref:../metering/metering-installing-metering.adoc#metering-install-operator_installing-metering[Metering Operator] is installed from OperatorHub.
|
||||
+
|
||||
[NOTE]
|
||||
@@ -43,11 +43,11 @@ Wait several seconds to allow the subscription to update before proceeding to th
|
||||
====
|
||||
. Click *Operators* -> *Installed Operators*.
|
||||
+
|
||||
The Metering Operator is shown as 4.5. For example:
|
||||
The Metering Operator is shown as 4.6. For example:
|
||||
+
|
||||
----
|
||||
Metering
|
||||
4.5.0-202007012112.p0 provided by Red Hat, Inc
|
||||
4.6.0-202007012112.p0 provided by Red Hat, Inc
|
||||
----
|
||||
|
||||
.Verification
|
||||
@@ -70,11 +70,11 @@ You can verify the metering upgrade by performing any of the following checks:
|
||||
$ oc get csv | grep metering
|
||||
----
|
||||
+
|
||||
.Example output for metering upgrade from 4.4 to 4.5
|
||||
.Example output for metering upgrade from 4.5 to 4.6
|
||||
[source,terminal]
|
||||
----
|
||||
NAME DISPLAY VERSION REPLACES PHASE
|
||||
metering-operator.4.5.0-202007012112.p0 Metering 4.5.0-202007012112.p0 metering-operator.4.4.0-202005252114 Succeeded
|
||||
metering-operator.4.6.0-202007012112.p0 Metering 4.6.0-202007012112.p0 metering-operator.4.5.0-202005252114 Succeeded
|
||||
----
|
||||
--
|
||||
|
||||
|
||||
@@ -50,8 +50,8 @@ Manage various aspects of the {product-title} release process, such as viewing i
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc adm release info --changelog=/tmp/git \
|
||||
quay.io/openshift-release-dev/ocp-release:4.5.0-rc.7-x86_64 \
|
||||
quay.io/openshift-release-dev/ocp-release:4.5.4-x86_64 \
|
||||
quay.io/openshift-release-dev/ocp-release:4.6.0-rc.7-x86_64 \
|
||||
quay.io/openshift-release-dev/ocp-release:4.6.4-x86_64 \
|
||||
> changelog.md
|
||||
----
|
||||
|
||||
|
||||
@@ -5,13 +5,8 @@
|
||||
[id="cluster-logging-collector-envvar_{context}"]
|
||||
= Configuring the logging collector using environment variables
|
||||
|
||||
You can use environment variables to modify the
|
||||
configuration of the Fluentd log collector.
|
||||
|
||||
[NOTE]
|
||||
===
|
||||
Configuring Fluentd using environment variables is deprecated in {product-title} 4.5. The process for configuring Fluentd will be different in {product-title} 4.6.
|
||||
===
|
||||
You can use environment variables to modify the configuration of the Fluentd log
|
||||
collector.
|
||||
|
||||
See the link:https://github.com/openshift/origin-aggregated-logging/blob/master/fluentd/README.md[Fluentd README] in Github for lists of the
|
||||
available environment variables.
|
||||
|
||||
@@ -131,14 +131,14 @@ metadata:
|
||||
name: "elasticsearch-operator"
|
||||
namespace: "openshift-operators-redhat" <1>
|
||||
spec:
|
||||
channel: "4.5" <2>
|
||||
channel: "4.6" <2>
|
||||
installPlanApproval: "Automatic"
|
||||
source: "redhat-operators" <3>
|
||||
sourceNamespace: "openshift-marketplace"
|
||||
name: "elasticsearch-operator"
|
||||
----
|
||||
<1> You must specify the `openshift-operators-redhat` Namespace.
|
||||
<2> Specify `4.5` as the channel.
|
||||
<2> Specify `4.6` as the channel.
|
||||
<3> Specify `redhat-operators`. If your {product-title} cluster is installed on a restricted network, also known as a disconnected cluster,
|
||||
specify the name of the CatalogSource object created when you configured the Operator Lifecycle Manager (OLM).
|
||||
|
||||
@@ -169,14 +169,14 @@ oc get csv --all-namespaces
|
||||
[source,terminal]
|
||||
----
|
||||
NAMESPACE NAME DISPLAY VERSION REPLACES PHASE
|
||||
default elasticsearch-operator.4.5.0-202007012112.p0 Elasticsearch Operator 4.5.0-202007012112.p0 Succeeded
|
||||
kube-node-lease elasticsearch-operator.4.5.0-202007012112.p0 Elasticsearch Operator 4.5.0-202007012112.p0 Succeeded
|
||||
kube-public elasticsearch-operator.4.5.0-202007012112.p0 Elasticsearch Operator 4.5.0-202007012112.p0 Succeeded
|
||||
kube-system elasticsearch-operator.4.5.0-202007012112.p0 Elasticsearch Operator 4.5.0-202007012112.p0 Succeeded
|
||||
openshift-apiserver-operator elasticsearch-operator.4.5.0-202007012112.p0 Elasticsearch Operator 4.5.0-202007012112.p0 Succeeded
|
||||
openshift-apiserver elasticsearch-operator.4.5.0-202007012112.p0 Elasticsearch Operator 4.5.0-202007012112.p0 Succeeded
|
||||
openshift-authentication-operator elasticsearch-operator.4.5.0-202007012112.p0 Elasticsearch Operator 4.5.0-202007012112.p0 Succeeded
|
||||
openshift-authentication elasticsearch-operator.4.5.0-202007012112.p0 Elasticsearch Operator 4.5.0-202007012112.p0 Succeeded
|
||||
default elasticsearch-operator.4.6.0-202007012112.p0 Elasticsearch Operator 4.6.0-202007012112.p0 Succeeded
|
||||
kube-node-lease elasticsearch-operator.4.6.0-202007012112.p0 Elasticsearch Operator 4.6.0-202007012112.p0 Succeeded
|
||||
kube-public elasticsearch-operator.4.6.0-202007012112.p0 Elasticsearch Operator 4.6.0-202007012112.p0 Succeeded
|
||||
kube-system elasticsearch-operator.4.6.0-202007012112.p0 Elasticsearch Operator 4.6.0-202007012112.p0 Succeeded
|
||||
openshift-apiserver-operator elasticsearch-operator.4.6.0-202007012112.p0 Elasticsearch Operator 4.6.0-202007012112.p0 Succeeded
|
||||
openshift-apiserver elasticsearch-operator.4.6.0-202007012112.p0 Elasticsearch Operator 4.6.0-202007012112.p0 Succeeded
|
||||
openshift-authentication-operator elasticsearch-operator.4.6.0-202007012112.p0 Elasticsearch Operator 4.6.0-202007012112.p0 Succeeded
|
||||
openshift-authentication elasticsearch-operator.4.6.0-202007012112.p0 Elasticsearch Operator 4.6.0-202007012112.p0 Succeeded
|
||||
...
|
||||
----
|
||||
+
|
||||
@@ -224,13 +224,13 @@ metadata:
|
||||
name: cluster-logging
|
||||
namespace: openshift-logging <1>
|
||||
spec:
|
||||
channel: "4.5" <2>
|
||||
channel: "4.6" <2>
|
||||
name: cluster-logging
|
||||
source: redhat-operators <3>
|
||||
sourceNamespace: openshift-marketplace
|
||||
----
|
||||
<1> You must specify the `openshift-logging` Namespace.
|
||||
<2> Specify `4.5` as the channel.
|
||||
<2> Specify `4.6` as the channel.
|
||||
<3> Specify `redhat-operators`. If your OpenShift Container Platform cluster is installed on a restricted network, also known as a disconnected cluster, specify the name of the CatalogSource object you created when you configured the Operator Lifecycle Manager (OLM).
|
||||
|
||||
.. Create the Subscription object:
|
||||
@@ -263,7 +263,7 @@ oc get csv -n openshift-logging
|
||||
----
|
||||
NAMESPACE NAME DISPLAY VERSION REPLACES PHASE
|
||||
...
|
||||
openshift-logging clusterlogging.4.5.0-202007012112.p0 Cluster Logging 4.5.0-202007012112.p0 Succeeded
|
||||
openshift-logging clusterlogging.4.6.0-202007012112.p0 Cluster Logging 4.6.0-202007012112.p0 Succeeded
|
||||
...
|
||||
----
|
||||
|
||||
|
||||
@@ -38,15 +38,15 @@ conflicts.
|
||||
|
||||
.. Select *Enable operator recommended cluster monitoring on this namespace*.
|
||||
+
|
||||
This option sets the `openshift.io/cluster-monitoring: "true"` label in the Namespace object.
|
||||
This option sets the `openshift.io/cluster-monitoring: "true"` label in the Namespace object.
|
||||
You must select this option to ensure that cluster monitoring
|
||||
scrapes the `openshift-operators-redhat` namespace.
|
||||
|
||||
.. Select *4.5* as the *Update Channel*.
|
||||
.. Select *4.6* as the *Update Channel*.
|
||||
|
||||
.. Select an *Approval Strategy*.
|
||||
+
|
||||
* The *Automatic* strategy allows Operator Lifecycle Manager (OLM) to automatically update the Operator when a new version is available.
|
||||
* The *Automatic* strategy allows Operator Lifecycle Manager (OLM) to automatically update the Operator when a new version is available.
|
||||
+
|
||||
* The *Manual* strategy requires a user with appropriate credentials to approve the Operator update.
|
||||
|
||||
@@ -72,11 +72,11 @@ This option sets the `openshift.io/cluster-monitoring: "true"` label in the Name
|
||||
You must select this option to ensure that cluster monitoring
|
||||
scrapes the `openshift-logging` namespace.
|
||||
|
||||
.. Select *4.5* as the *Update Channel*.
|
||||
.. Select *4.6* as the *Update Channel*.
|
||||
|
||||
.. Select an *Approval Strategy*.
|
||||
+
|
||||
* The *Automatic* strategy allows Operator Lifecycle Manager (OLM) to automatically update the Operator when a new version is available.
|
||||
* The *Automatic* strategy allows Operator Lifecycle Manager (OLM) to automatically update the Operator when a new version is available.
|
||||
+
|
||||
* The *Manual* strategy requires a user with appropriate credentials to approve the Operator update.
|
||||
|
||||
@@ -208,9 +208,9 @@ However, an unmanaged deployment does not receive updates until the cluster logg
|
||||
<3> Settings for configuring Elasticsearch. Using the CR, you can configure shard replication policy and persistent storage.
|
||||
<4> Specify the length of time that Elasticsearch should retain each log source. Enter an integer and a time designation: weeks(w), hours(h/H), minutes(m) and seconds(s). For example, `7d` for seven days. Logs older than the `maxAge` are deleted. You must specify a retention policy for each log source or the Elasticsearch indices will not be created for that source.
|
||||
<5> Specify the number of Elasticsearch nodes. See the note that follows this list.
|
||||
<6> Enter the name of an existing StorageClass for Elasticsearch storage. For best performance, specify a StorageClass that allocates block storage.
|
||||
<6> Enter the name of an existing StorageClass for Elasticsearch storage. For best performance, specify a StorageClass that allocates block storage.
|
||||
<7> Settings for configuring Kibana. Using the CR, you can scale Kibana for redundancy and configure the CPU and memory for your Kibana nodes. For more information, see *Configuring Kibana*.
|
||||
<8> Settings for configuring the Curator schedule. Curator is used to remove data that is in the Elasticsearch index format prior to {product-title} 4.5 and will be removed in a later release.
|
||||
<8> Settings for configuring the Curator schedule. Curator is used to remove data that is in the Elasticsearch index format prior to {product-title} 4.5 and will be removed in a later release.
|
||||
<9> Settings for configuring Fluentd. Using the CR, you can configure Fluentd CPU and memory limits. For more information, see *Configuring Fluentd*.
|
||||
+
|
||||
[NOTE]
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
[id="cluster-logging-updating-logging_{context}"]
|
||||
= Updating cluster logging
|
||||
|
||||
After updating the {product-title} cluster, you can update cluster logging from 4.4 to 4.5 by changing the subscription for the Elasticsearch Operator and the Cluster Logging Operator.
|
||||
After updating the {product-title} cluster, you can update cluster logging from 4.5 to 4.6 by changing the subscription for the Elasticsearch Operator and the Cluster Logging Operator.
|
||||
|
||||
When you update:
|
||||
|
||||
@@ -18,12 +18,12 @@ If you update the Cluster Logging Operator before the Elasticsearch Operator, Ki
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
If your cluster logging version is prior to 4.4, you must upgrade cluster logging to 4.4 before updating to 4.5.
|
||||
If your cluster logging version is prior to 4.5, you must upgrade cluster logging to 4.5 before updating to 4.6.
|
||||
====
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* Update the {product-title} cluster from 4.4 to 4.5.
|
||||
* Update the {product-title} cluster from 4.5 to 4.6.
|
||||
|
||||
* Make sure the cluster logging status is healthy:
|
||||
+
|
||||
@@ -44,16 +44,16 @@ If your cluster logging version is prior to 4.4, you must upgrade cluster loggin
|
||||
|
||||
.. Click *Subscription* -> *Channel*.
|
||||
|
||||
.. In the *Change Subscription Update Channel* window, select *4.5* and click *Save*.
|
||||
.. In the *Change Subscription Update Channel* window, select *4.6* and click *Save*.
|
||||
|
||||
.. Wait for a few seconds, then click *Operators* -> *Installed Operators*.
|
||||
+
|
||||
The Elasticsearch Operator is shown as 4.5. For example:
|
||||
The Elasticsearch Operator is shown as 4.6. For example:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
Elasticsearch Operator
|
||||
4.5.0-202007012112.p0 provided
|
||||
4.6.0-202007012112.p0 provided
|
||||
by Red Hat, Inc
|
||||
----
|
||||
+
|
||||
@@ -69,16 +69,16 @@ Wait for the *Status* field to report *Succeeded*.
|
||||
|
||||
.. Click *Subscription* -> *Channel*.
|
||||
|
||||
.. In the *Change Subscription Update Channel* window, select *4.5* and click *Save*.
|
||||
.. In the *Change Subscription Update Channel* window, select *4.6* and click *Save*.
|
||||
|
||||
.. Wait for a few seconds, then click *Operators* -> *Installed Operators*.
|
||||
+
|
||||
The Cluster Logging Operator is shown as 4.5. For example:
|
||||
The Cluster Logging Operator is shown as 4.6. For example:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
Cluster Logging
|
||||
4.5.0-202007012112.p0 provided
|
||||
4.6.0-202007012112.p0 provided
|
||||
by Red Hat, Inc
|
||||
----
|
||||
+
|
||||
@@ -142,7 +142,7 @@ elasticsearch-rollover-audit */15 * * * * False 0 <none>
|
||||
elasticsearch-rollover-infra */15 * * * * False 0 <none> 27s
|
||||
----
|
||||
|
||||
.. Verify that the log store is updated to 4.5 and the indices are `green`:
|
||||
.. Verify that the log store is updated to 4.6 and the indices are `green`:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
@@ -187,7 +187,7 @@ green open infra-000013
|
||||
green open audit-000001 eERqLdLmQOiQDFES1LBATQ 3 1 0 0 0 0
|
||||
----
|
||||
|
||||
.. Verify that the log collector is updated to 4.5:
|
||||
.. Verify that the log collector is updated to 4.6:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
@@ -201,7 +201,7 @@ You should see a `fluentd-init` container:
|
||||
"containerName": "fluentd-init"
|
||||
----
|
||||
|
||||
.. Verify that the log visualizer is updated to 4.5 using the Kibana CRD:
|
||||
.. Verify that the log visualizer is updated to 4.6 using the Kibana CRD:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
@@ -244,7 +244,7 @@ You should see a Kibana Pod with the `ready` status:
|
||||
]
|
||||
----
|
||||
|
||||
.. Verify the Curator is updated to 4.5:
|
||||
.. Verify the Curator is updated to 4.6:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
@@ -264,14 +264,8 @@ cronjob.batch/elasticsearch-rollover-infra
|
||||
+
|
||||
You should see the `elasticsearch-delete-\*` and `elasticsearch-rollover-*` indices.
|
||||
|
||||
.Post update
|
||||
== Post-update tasks
|
||||
|
||||
If you use Kibana, after the Elasticsearch Operator and Cluster Logging Operator are fully updated to 4.5, you must perform the following actions to complete the upgrade:
|
||||
|
||||
* Recreate your Kibana index patterns. Because of changes in the security plug-in, the cluster logging upgrade does not automatically create index patterns.
|
||||
|
||||
** Regular users must manually create index patterns to see logs for their projects. Because of the new Elasticsearch data model, all logs that were stored in an index prefixed with *project-* in {product-title} 4.4 are now in a set of indices prefixed with *app-*. Users should create a new index patterns named `app` and use the `@timestamp` time field to view their container logs. To view historical data gathered by cluster logging 4.4, users need to create index patterns using `project*` field.
|
||||
|
||||
** Admin users need to create index patterns using the *app*, *infra* and *audit* prefix with the `@timestamp` time field. The *infra-* indices were previously *.operations-*. The *audit-* indices are the audit logs. To view historical data gathered by cluster logging 4.4, admin users need to create index patterns using the `.operation*` field to view system logs and create index patterns using the `project*` field to view project-level logs.
|
||||
|
||||
* Recreate your Kibana Visualizations to use the new index patterns.
|
||||
If you use Kibana, after the Elasticsearch Operator and Cluster Logging Operator
|
||||
are fully updated to 4.6, you must recreate your Kibana index patterns and
|
||||
visualizations.
|
||||
|
||||
@@ -58,7 +58,7 @@ spec:
|
||||
----
|
||||
|
||||
<1> Valid values are `true` or `false`. Setting the `true` value installs the real-time kernel on the node.
|
||||
<2> New for {product-title} 4.5. Use this field to configure the topology manager policy. Valid values are `none` (default),
|
||||
<2> Use this field to configure the topology manager policy. Valid values are `none` (default),
|
||||
`best-effort`, `restricted`, and `single-numa-node`. For more information, see
|
||||
link:https://kubernetes.io/docs/tasks/administer-cluster/topology-manager/#topology-manager-policies[Topology Manager Policies].
|
||||
|
||||
|
||||
@@ -118,14 +118,14 @@ Check that there are no cluster Operators with the `DEGRADED` condition set to `
|
||||
[source,terminal]
|
||||
----
|
||||
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE
|
||||
authentication 4.5.0 True False False 59m
|
||||
cloud-credential 4.5.0 True False False 85m
|
||||
cluster-autoscaler 4.5.0 True False False 73m
|
||||
config-operator 4.5.0 True False False 73m
|
||||
console 4.5.0 True False False 62m
|
||||
csi-snapshot-controller 4.5.0 True False False 66m
|
||||
dns 4.5.0 True False False 76m
|
||||
etcd 4.5.0 True False False 76m
|
||||
authentication 4.6.0 True False False 59m
|
||||
cloud-credential 4.6.0 True False False 85m
|
||||
cluster-autoscaler 4.6.0 True False False 73m
|
||||
config-operator 4.6.0 True False False 73m
|
||||
console 4.6.0 True False False 62m
|
||||
csi-snapshot-controller 4.6.0 True False False 66m
|
||||
dns 4.6.0 True False False 76m
|
||||
etcd 4.6.0 True False False 76m
|
||||
...
|
||||
----
|
||||
|
||||
|
||||
@@ -11,5 +11,5 @@
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ sudo podman pull quay.io/openshift/origin-tests:4.5
|
||||
$ sudo podman pull quay.io/openshift/origin-tests:4.6
|
||||
----
|
||||
|
||||
@@ -10,6 +10,6 @@ The latest-4.x can be used to deploy the latest Generally
|
||||
Available version of {product-title}:
|
||||
|
||||
----
|
||||
[kni@provisioner ~]$ export VERSION=latest-4.5
|
||||
[kni@provisioner ~]$ export VERSION=latest-4.6
|
||||
export RELEASE_IMAGE=$(curl -s https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/release.txt | grep 'Pull From: quay.io' | awk -F ' ' '{print $3}')
|
||||
----
|
||||
|
||||
@@ -37,7 +37,7 @@ If you have already installed the Elasticsearch Operator as part of OpenShift cl
|
||||
|
||||
. On the *Create Operator Subscription* page, select the *A specific namespace on the cluster* option and then select *openshift-operators-redhat* from the menu.
|
||||
|
||||
. Select the *Update Channel* that matches your {product-title} installation. For example, if you are installing on {product-title} version 4.5, select the 4.5 update channel.
|
||||
. Select the *Update Channel* that matches your {product-title} installation. For example, if you are installing on {product-title} version 4.6, select the 4.6 update channel.
|
||||
|
||||
. Select the *Automatic* Approval Strategy.
|
||||
+
|
||||
|
||||
@@ -86,7 +86,7 @@ metadata:
|
||||
name: clusterresourceoverride
|
||||
namespace: clusterresourceoverride-operator
|
||||
spec:
|
||||
channel: "4.5"
|
||||
channel: "4.6"
|
||||
name: clusterresourceoverride
|
||||
source: redhat-operators
|
||||
sourceNamespace: openshift-marketplace
|
||||
|
||||
@@ -90,7 +90,7 @@ metadata:
|
||||
labels:
|
||||
beta.kubernetes.io/os: linux
|
||||
failure-domain.beta.kubernetes.io/zone: us-east-1a
|
||||
node.openshift.io/os_version: '4.5'
|
||||
node.openshift.io/os_version: '4.6'
|
||||
node-role.kubernetes.io/worker: ''
|
||||
failure-domain.beta.kubernetes.io/region: us-east-1
|
||||
node.openshift.io/os_id: rhcos
|
||||
|
||||
@@ -36,14 +36,14 @@ local file system:
|
||||
[source,terminal]
|
||||
ifdef::openshift-origin[]
|
||||
----
|
||||
$ oc image extract quay.io/openshift/origin-operator-registry:4.5.0 \
|
||||
$ oc image extract quay.io/openshift/origin-operator-registry:4.6.0 \
|
||||
--path /usr/bin/opm:. \
|
||||
--confirm
|
||||
----
|
||||
endif::[]
|
||||
ifdef::openshift-enterprise,openshift-webscale[]
|
||||
----
|
||||
$ oc image extract registry.redhat.io/openshift4/ose-operator-registry:v4.5 \
|
||||
$ oc image extract registry.redhat.io/openshift4/ose-operator-registry:v4.6 \
|
||||
-a ${REG_CREDS} \//<1>
|
||||
--path /usr/bin/opm:. \
|
||||
--confirm
|
||||
|
||||
@@ -42,9 +42,9 @@ You must not enable firewalld later. If you do, you cannot access {product-title
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
# subscription-manager repos --disable=rhel-7-server-ose-4.4-rpms \
|
||||
# subscription-manager repos --disable=rhel-7-server-ose-4.5-rpms \
|
||||
--enable=rhel-7-server-ansible-2.9-rpms \
|
||||
--enable=rhel-7-server-ose-4.5-rpms
|
||||
--enable=rhel-7-server-ose-4.6-rpms
|
||||
----
|
||||
|
||||
.. On the machine that you run the Ansible playbooks, update the required packages, including `openshift-ansible`:
|
||||
@@ -58,8 +58,8 @@ You must not enable firewalld later. If you do, you cannot access {product-title
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
# subscription-manager repos --disable=rhel-7-server-ose-4.4-rpms \
|
||||
--enable=rhel-7-server-ose-4.5-rpms
|
||||
# subscription-manager repos --disable=rhel-7-server-ose-4.5-rpms \
|
||||
--enable=rhel-7-server-ose-4.6-rpms
|
||||
----
|
||||
|
||||
. Update a RHEL worker machine:
|
||||
|
||||
@@ -78,7 +78,7 @@ Note that this might take a few minutes if you have a large number of available
|
||||
# subscription-manager repos \
|
||||
--enable="rhel-7-server-rpms" \
|
||||
--enable="rhel-7-server-extras-rpms" \
|
||||
--enable="rhel-7-server-ose-4.5-rpms"
|
||||
--enable="rhel-7-server-ose-4.6-rpms"
|
||||
----
|
||||
|
||||
. Stop and disable firewalld on the host:
|
||||
|
||||
@@ -19,7 +19,7 @@ template builds and waits for them to complete:
|
||||
[source,terminal]
|
||||
----
|
||||
$ sudo podman run -v ${LOCAL_KUBECONFIG}:/root/.kube/config:z -i \
|
||||
quay.io/openshift/origin-tests:4.5 /bin/bash -c 'export KUBECONFIG=/root/.kube/config && \
|
||||
quay.io/openshift/origin-tests:4.6 /bin/bash -c 'export KUBECONFIG=/root/.kube/config && \
|
||||
openshift-tests run-test "[sig-scalability][Feature:Performance] Load cluster \
|
||||
should populate the cluster [Slow][Serial] [Suite:openshift]"'
|
||||
----
|
||||
@@ -31,7 +31,7 @@ setting the environment variable for `VIPERCONFIG`:
|
||||
----
|
||||
$ sudo podman run -v ${LOCAL_KUBECONFIG}:/root/.kube/config:z \
|
||||
-v ${LOCAL_CONFIG_FILE_PATH}:/root/configs/:z \
|
||||
-i quay.io/openshift/origin-tests:4.5 \
|
||||
-i quay.io/openshift/origin-tests:4.6 \
|
||||
/bin/bash -c 'KUBECONFIG=/root/.kube/config VIPERCONFIG=/root/configs/test.yaml \
|
||||
openshift-tests run-test "[sig-scalability][Feature:Performance] Load cluster \
|
||||
should populate the cluster [Slow][Serial] [Suite:openshift]"'
|
||||
|
||||
@@ -21,7 +21,7 @@ If you have selected Manual updates, you will need to complete additional steps
|
||||
. Navigate to the *Operators* → *Installed Operators* page.
|
||||
. Select the *{ServerlessOperatorName} Operator*.
|
||||
. Click *Subscription* → *Channel*.
|
||||
. In the *Change Subscription Update Channel* window, select `4.5`, and then click *Save*.
|
||||
. In the *Change Subscription Update Channel* window, select `4.6`, and then click *Save*.
|
||||
. Wait until all pods have been upgraded in the `knative-serving` namespace and the KnativeServing custom resource reports the latest Knative Serving version.
|
||||
|
||||
.Verification steps
|
||||
|
||||
Reference in New Issue
Block a user