mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
Release notes for OSSM 1.1.4
This commit is contained in:
Julie Stickler
committed by
openshift-cherrypick-robot
openshift-cherrypick-robot
parent
0cd23a04c9
commit
68d57d465c
@@ -12,7 +12,7 @@
|
||||
:ProductName: Red Hat OpenShift Service Mesh
|
||||
:ProductShortName: Service Mesh
|
||||
:ProductRelease:
|
||||
:ProductVersion: 1.1.3
|
||||
:ProductVersion: 1.1.4
|
||||
:MaistraVersion: 1.1
|
||||
:product-build:
|
||||
:DownloadURL: registry.redhat.io
|
||||
|
||||
@@ -19,7 +19,7 @@ The following issues been resolved in the current release:
|
||||
[id="ossm-rn-fixed-issues-ossm_{context}"]
|
||||
== {ProductShortName} fixed issues
|
||||
|
||||
* link:https://issues.redhat.com/browse/MAISTRA-1352[MAISTRA-1352] Cert-manager Custom Resource Definitions (CRD) from the control plane installation have been removed for this release and future releases. If you have already installed {ProductName}, the CRDs must be removed manually if cert-manager is not being used.
|
||||
* link:https://issues.redhat.com/browse/MAISTRA-1352[MAISTRA-1352] Cert-manager Custom Resource Definitions (CRD) from the control plane installation have been removed for this release and future releases. If you have already installed {ProductName}, the CRDs must be removed manually if cert-manager is not being used.
|
||||
+
|
||||
To remove the CRDs, run the following commands:
|
||||
+
|
||||
@@ -66,6 +66,10 @@ $ oc delete crd challenges.certmanager.k8s.io
|
||||
|
||||
* link:https://issues.jboss.org/browse/KIALI-3239[KIALI-3239] If a Kiali Operator pod has failed with a status of “Evicted” it blocks the Kiali operator from deploying. The workaround is to delete the Evicted pod and redeploy the Kiali operator.
|
||||
|
||||
* link:https://issues.jboss.org/browse/KIALI-3096[KIALI-3096] Runtime metrics fail in {ProductShortName}. There is an OAuth filter between the {ProductShortname} and Prometheus, requiring a bearer token to be passed to Prometheus before access will be granted. Kiali has been updated to use this token when communicating to the Prometheus server, but the application metrics are currently failing with 403 errors.
|
||||
* link:https://issues.jboss.org/browse/KIALI-3118[KIALI-3118] After changes to the ServiceMeshMemberRoll, for example adding or removing projects, the Kiali pod restarts and then displays errors on the Graph page while the Kiali pod is restarting.
|
||||
|
||||
* link:https://issues.jboss.org/browse/KIALI-3096[KIALI-3096] Runtime metrics fail in {ProductShortName}. There is an OAuth filter between the {ProductShortname} and Prometheus, requiring a bearer token to be passed to Prometheus before access is granted. Kiali has been updated to use this token when communicating to the Prometheus server, but the application metrics are currently failing with 403 errors.
|
||||
|
||||
* link:https://issues.jboss.org/browse/KIALI-3070[KIALI-3070] This bug only affects custom dashboards, not the default dashboards. When you select labels in metrics settings and refresh the page, your selections are retained in the menu but your selections are not displayed on the charts.
|
||||
|
||||
* link:https://github.com/kiali/kiali/issues/1603[KIALI-2686] When the control plane has many namespaces, it can lead to performance issues.
|
||||
|
||||
@@ -19,6 +19,8 @@ These limitations exist in {ProductName}:
|
||||
|
||||
* Graph layout - The layout for the Kiali graph can render differently, depending on your application architecture and the data to display (number of graph nodes and their interactions). Because it is difficult if not impossible to create a single layout that renders nicely for every situation, Kiali offers a choice of several different layouts. To choose a different layout, you can choose a different *Layout Schema* from the *Graph Settings* menu.
|
||||
|
||||
* The first time you access related services such as Jaeger and Grafana, from the Kiali console, you must accept the certificate and re-authenticate using your {product-title} login credentials. This happens due to an issue with how the framework displays embedded pages in the console.
|
||||
|
||||
[id="ossm-rn-known-issues-ossm_{context}"]
|
||||
== {ProductShortName} known issues
|
||||
|
||||
@@ -37,9 +39,13 @@ These are the known issues in {ProductName}:
|
||||
** [2019-06-03 07:03:28.943][19][warning][misc] [external/envoy/source/common/protobuf/utility.cc:129] Using deprecated option 'envoy.api.v2.listener.Filter.config'. This configuration will be removed from Envoy soon.
|
||||
** [2019-08-12 22:12:59.001][13][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Listener.use_original_dst' from file lds.proto. This configuration will be removed from Envoy soon.
|
||||
|
||||
* link:https://issues.jboss.org/browse/MAISTRA-681[MAISTRA-681] and link:https://issues.jboss.org/browse/KIALI-2686[KIALI-2686] When the control plane has many namespaces, it can lead to performance issues.
|
||||
* link:https://issues.jboss.org/browse/MAISTRA-806[MAISTRA-806] Evicted Istio Operator Pod causes mesh and CNI not to deploy.
|
||||
+
|
||||
If the `istio-operator` pod is evicted while deploying the control pane, delete the evicted `istio-operator` pod.
|
||||
+
|
||||
* link:https://issues.jboss.org/browse/MAISTRA-681[MAISTRA-681] When the control plane has many namespaces, it can lead to performance issues.
|
||||
|
||||
* link:https://issues.jboss.org/browse/MAISTRA-465[MAISTRA-465] The Maistra operator fails to create a service for operator metrics.
|
||||
* link:https://issues.jboss.org/browse/MAISTRA-465[MAISTRA-465] The Maistra Operator fails to create a service for operator metrics.
|
||||
|
||||
* link:https://issues.jboss.org/browse/MAISTRA-453[MAISTRA-453] If you create a new project and deploy pods immediately, sidecar injection does not occur. The operator fails to add the `maistra.io/member-of` before the pods are created, therefore the pods must be deleted and recreated for sidecar injection to occur.
|
||||
|
||||
@@ -47,19 +53,13 @@ These are the known issues in {ProductName}:
|
||||
|
||||
* link:https://issues.jboss.org/browse/MAISTRA-158[MAISTRA-158] Applying multiple gateways referencing the same hostname will cause all gateways to stop functioning.
|
||||
|
||||
* link:https://issues.jboss.org/browse/MAISTRA-806[MAISTRA-806] Evicted Istio Operator Pod causes mesh and CNI not to deploy.
|
||||
+
|
||||
If the `istio-operator` pod is evicted while deploying the control pane, delete the evicted `istio-operator` pod.
|
||||
|
||||
|
||||
[id="ossm-rn-known-issues-kiali_{context}"]
|
||||
== Kiali known issues
|
||||
|
||||
These are the known issues in Kiali:
|
||||
|
||||
* link:https://issues.jboss.org/browse/KIALI-3262[KIALI-3262] In the Kiali console, when you click on Distributed Tracing in the navigation or on a Traces tab, you are asked to accept the certificate, and then asked to provide your OpenShift login credentials. This happens due to an issue with how the framework displays the Trace pages in the Console. The Workaround is to open the URL for the Jaeger console in another browser window and log in. Then you can view the embedded tracing pages in the Kiali console.
|
||||
|
||||
* link:https://issues.jboss.org/browse/KIALI-3118[KIALI-3118] After changes to the ServiceMeshMemberRoll, for example adding or removing projects, the Kiali pod restarts and then displays errors on the Graph page while the Kiali pod is restarting.
|
||||
|
||||
* link:https://issues.jboss.org/browse/KIALI-2206[KIALI-2206] When you are accessing the Kiali console for the first time, and there is no cached browser data for Kiali, the “View in Grafana” link on the Metrics tab of the Kiali Service Details page redirects to the wrong location. The only way you would encounter this issue is if you are accessing Kiali for the first time.
|
||||
|
||||
* link:https://github.com/kiali/kiali/issues/507[KIALI-507] Kiali does not support Internet Explorer 11. This is because the underlying frameworks do not support Internet Explorer. To access the Kiali console, use one of the two most recent versions of the Chrome, Edge, Firefox or Safari browser.
|
||||
|
||||
@@ -35,9 +35,18 @@ Result – If changed, describe the current user experience
|
||||
|1.0.0
|
||||
|===
|
||||
|
||||
== New features {ProductName} 1.1.4
|
||||
|
||||
This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
There are manual steps that must be completed with this update.
|
||||
====
|
||||
|
||||
== New features {ProductName} 1.1.3
|
||||
|
||||
This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.
|
||||
This release of {ProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.
|
||||
|
||||
== New features {ProductName} 1.1.2
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
[id="seting_up_topology_manager_{context}"]
|
||||
= Setting up Topology Manager
|
||||
|
||||
To use Topology Manager, you must enable the `LatencySensitive` Feature Gate and configure the Topology Manager policy in the `cpumanager-enabled` custom resource (CR). This file might exist if you have set up CPU Manager. If the file does not exist, you can create the file.
|
||||
To use Topology Manager, you must enable the `LatencySensitive` Feature Gate and configure the Topology Manager policy in the `cpumanager-enabled` custom resource (CR). This file might exist if you have set up CPU Manager. If the file does not exist, you can create the file.
|
||||
|
||||
.Prequisites
|
||||
|
||||
@@ -21,7 +21,7 @@ To activate Topololgy Manager:
|
||||
$ oc edit featuregate/cluster
|
||||
----
|
||||
+
|
||||
[source yaml]
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: config.openshift.io/v1
|
||||
kind: FeatureGate
|
||||
@@ -60,7 +60,7 @@ spec:
|
||||
----
|
||||
<1> Add the `LatencySensitive` feature set in a comma-separated list.
|
||||
|
||||
. Configure the Topology Manager policy in the `cpumanager-enabled` custom resource (CR).
|
||||
. Configure the Topology Manager policy in the `cpumanager-enabled` custom resource (CR).
|
||||
+
|
||||
----
|
||||
$ oc edit KubeletConfig cpumanager-enabled
|
||||
@@ -84,4 +84,3 @@ spec:
|
||||
<1> This parameter must be `static`.
|
||||
<2> Specify your selected Topology Manager policy. Here, the policy is `single-numa-node`.
|
||||
Acceptable values are: `default`, `best-effort`, `restricted`, `single-numa-node`.
|
||||
|
||||
|
||||
@@ -4,9 +4,86 @@ include::modules/ossm-document-attributes.adoc[]
|
||||
:context: updating-ossm
|
||||
toc::[]
|
||||
|
||||
If you are updating from {ProductName} 1.0 to 1.1, you must update the `ServiceMeshControlPlane` resource to update the control plane components to the new version.
|
||||
|
||||
. In the web console, click the {ProductName} operator.
|
||||
== Manual updates required by version 1.1.4
|
||||
|
||||
The fix for link:https://bugzilla.redhat.com/show_bug.cgi?id=1844254[CVE-2020-8663]`: envoy: Resource exhaustion when accepting too many connections` added a configurable limit on downstream connections. The configuration option for this limit must be configured to mitigate this vulnerability.
|
||||
|
||||
This new configuration option is called `overload.global_downstream_max_connections`, and it is configurable as a proxy `runtime` setting. Perform the following steps to configure limits at the Ingress Gateway.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Create a file named `bootstrap-override.json` with the following text to force the proxy to override the bootstrap template and load runtime configuration from disk:
|
||||
+
|
||||
{
|
||||
"runtime": {
|
||||
"symlink_root": "/var/lib/istio/envoy/runtime"
|
||||
}
|
||||
}
|
||||
+
|
||||
. Create a secret from the `bootstrap-override.json` file, replacing <SMCPnamespace> with the namespace where you created the service mesh control plane (SMCP):
|
||||
+
|
||||
$ oc create secret generic -n <SMCPnamespace> gateway-bootstrap --from-file=bootstrap-override.json
|
||||
+
|
||||
. Update the SMCP configuration to activate the override.
|
||||
|
||||
+
|
||||
.Updated SMCP configuration example #1
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: maistra.io/v1
|
||||
kind: ServiceMeshControlPlane
|
||||
spec:
|
||||
istio:
|
||||
gateways:
|
||||
istio-ingressgateway:
|
||||
env:
|
||||
ISTIO_BOOTSTRAP_OVERRIDE: /var/lib/istio/envoy/custom-bootstrap/bootstrap-override.json
|
||||
secretVolumes:
|
||||
- mountPath: /var/lib/istio/envoy/custom-bootstrap
|
||||
name: custom-bootstrap
|
||||
secretName: gateway-bootstrap
|
||||
----
|
||||
+
|
||||
|
||||
. To set the new configuration option, create a secret that has the desired value for the `overload.global_downstream_max_connections` setting. The following example uses a value of `10000`:
|
||||
+
|
||||
$ oc create secret generic -n <SMCPnamespace> gateway-settings --from-literal=overload.global_downstream_max_connections=10000
|
||||
+
|
||||
|
||||
. Update the SMCP again to mount the secret in the location where Envoy is looking for runtime configuration:
|
||||
|
||||
.Updated SMCP configuration example #2
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: maistra.io/v1
|
||||
kind: ServiceMeshControlPlane
|
||||
spec:
|
||||
template: default
|
||||
version: v1.1
|
||||
istio:
|
||||
gateways:
|
||||
istio-ingressgateway:
|
||||
env:
|
||||
ISTIO_BOOTSTRAP_OVERRIDE: /var/lib/istio/envoy/custom-bootstrap/bootstrap-override.json
|
||||
secretVolumes:
|
||||
- mountPath: /var/lib/istio/envoy/custom-bootstrap
|
||||
name: custom-bootstrap
|
||||
secretName: gateway-bootstrap
|
||||
# below is the new secret mount
|
||||
- mountPath: /var/lib/istio/envoy/runtime
|
||||
name: gateway-settings
|
||||
secretName: gateway-settings
|
||||
|
||||
----
|
||||
|
||||
|
||||
[id="ossm-manual-updates-1.0-1.1_{context}"]
|
||||
== Manual updates from 1.0 to 1.1
|
||||
|
||||
If you are updating from {ProductName} 1.0 to 1.1, you must update the `ServiceMeshControlPlane` resource to update the control plane components to the new version.
|
||||
|
||||
. In the web console, click the {ProductName} Operator.
|
||||
|
||||
. Click the *Project* menu and choose the project where your `ServiceMeshControlPlane` is deployed from the list, for example `istio-system`.
|
||||
|
||||
@@ -22,6 +99,7 @@ spec:
|
||||
|
||||
The version field specifies the version of ServiceMesh to install and defaults to the latest available version.
|
||||
|
||||
[id="ossm-manual-updates_{context}"]
|
||||
== Manual updates
|
||||
|
||||
If you choose to update manually, the Operator Lifecycle Manager (OLM) controls the installation, upgrade, and role-based access control (RBAC) of Operators in a cluster. OLM runs by default in {product-title}.
|
||||
|
||||
Reference in New Issue
Block a user