|
1 | 1 | <!--toc--> |
2 | | -- [v1.9.3](#v193) |
3 | | - - [Changelog since v1.9.2](#changelog-since-v192) |
| 2 | +- [v1.9.4](#v194) |
| 3 | + - [Changelog since v1.9.3](#changelog-since-v193) |
4 | 4 | - [Known Issues](#known-issues) |
5 | 5 | - [Changes by Kind](#changes-by-kind) |
6 | | - - [Features](#features) |
7 | 6 | - [Bugs](#bugs) |
8 | | -- [v1.9.2](#v192) |
9 | | - - [Changelog since v1.9.1](#changelog-since-v191) |
| 7 | +- [v1.9.3](#v193) |
| 8 | + - [Changelog since v1.9.2](#changelog-since-v192) |
10 | 9 | - [Known Issues](#known-issues-1) |
11 | 10 | - [Changes by Kind](#changes-by-kind-1) |
| 11 | + - [Features](#features-1) |
12 | 12 | - [Bugs](#bugs-1) |
13 | | -- [v1.9.1](#v191) |
14 | | - - [Changelog since v1.9.0](#changelog-since-v190) |
| 13 | +- [v1.9.2](#v192) |
| 14 | + - [Changelog since v1.9.1](#changelog-since-v191) |
15 | 15 | - [Known Issues](#known-issues-2) |
16 | 16 | - [Changes by Kind](#changes-by-kind-2) |
17 | 17 | - [Bugs](#bugs-2) |
18 | | -- [v1.9.0](#v190) |
19 | | - - [Changelog since v1.8.0](#changelog-since-v180) |
| 18 | +- [v1.9.1](#v191) |
| 19 | + - [Changelog since v1.9.0](#changelog-since-v190) |
20 | 20 | - [Known Issues](#known-issues-3) |
21 | 21 | - [Changes by Kind](#changes-by-kind-3) |
| 22 | + - [Bugs](#bugs-3) |
| 23 | +- [v1.9.0](#v190) |
| 24 | + - [Changelog since v1.8.0](#changelog-since-v180) |
| 25 | + - [Known Issues](#known-issues-4) |
| 26 | + - [Changes by Kind](#changes-by-kind-4) |
22 | 27 | - [Deprecation](#deprecation) |
23 | 28 | - [Features](#features-1) |
24 | | - - [Bugs](#bugs-3) |
| 29 | + - [Bugs](#bugs-4) |
25 | 30 |
|
| 31 | +# v1.9.4 |
| 32 | + |
| 33 | +## Changelog since v1.9.3 |
| 34 | + |
| 35 | +## Known Issues |
| 36 | + |
| 37 | +- The status field of a csm object as deployed by CSM Operator may, in limited cases, display an incorrect status for a deployment. As a workaround, the health of the deployment can be determined by checking the health of the pods. |
| 38 | +- When CSM Operator creates a deployment that includes secrets (e.g., application-mobility, observability, cert-manager, velero), these secrets are not deleted on uninstall and will be left behind. For example, the `karavi-topology-tls`, `otel-collector-tls`, and `cert-manager-webhook-ca` secrets will not be deleted. This should not cause any issues on the system, but all secrets present on the cluster can be found with `kubectl get secrets -A`, and any unwanted secrets can be deleted with `kubectl delete secret -n <secret-namespace> <secret-name>` |
| 39 | + |
| 40 | +## Changes by Kind |
| 41 | + |
| 42 | +### Bugs |
| 43 | +- Change the Apex Connectivity Client access to the kube-proxy port to only connections within the client pod. ([#1189](https://github.com/dell/csm/issues/1189)) |
| 44 | +- Change Apex Connectivity Client access to secrets to only the secrets it needs to manage. ([#1190](https://github.com/dell/csm/issues/1190)) |
| 45 | + |
26 | 46 | # v1.9.3 |
27 | 47 |
|
28 | 48 | ## Changelog since v1.9.2 |
|
0 commit comments