OADP-7566: Add 1.4.9 RNs#109004
Conversation
|
@vashirova: This pull request references OADP-7566 which is a valid jira issue. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
/label OADP |
|
🤖 Wed Mar 25 16:34:55 - Prow CI generated the docs preview: |
|
@vashirova: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
@vashirova: This pull request references OADP-7566 which is a valid jira issue. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
@weshayutin, @akarol, @anarnold97, could you please review OADP 1.4.9 release notes? Are they accurate and complete? Note that I didn't include OADP-5473 based on Fix versions and Status, but lemme know if I should. Thank you! |
|
THANK YOU!! |
| + | ||
| link:https://redhat.atlassian.net/browse/OADP-3143[OADP-3143] | ||
|
|
||
| DPA reconciliation fails with a clear error when a VSL references missing credential key:: |
There was a problem hiding this comment.
| DPA reconciliation fails with a clear error when a VSL references missing credential key:: | |
| DPA reconciliation fails with a clear error when a VSL references a missing credential key:: |
| link:https://redhat.atlassian.net/browse/OADP-4833[OADP-4833] | ||
|
|
||
| Restricted permissions for Velero cloud credentials:: | ||
| Before this update, Velero `/credentials/cloud` secret was mounted with incorrect permissions, making it world-readable. As a consequence, any process or user with access to the container file system could read sensitive cloud credential data. With this release, the Velero secret default permissions were changed to `0640`. As a result, access to the credentials file is limited to the intended owner or group. |
There was a problem hiding this comment.
| Before this update, Velero `/credentials/cloud` secret was mounted with incorrect permissions, making it world-readable. As a consequence, any process or user with access to the container file system could read sensitive cloud credential data. With this release, the Velero secret default permissions were changed to `0640`. As a result, access to the credentials file is limited to the intended owner or group. | |
| Before this update, the Velero `/credentials/cloud` secret was mounted with incorrect permissions, making it world-readable. As a consequence, any process or user with access to the container file system could read sensitive cloud credential data. With this release, the Velero secret default permissions were changed to `0640`. As a result, access to the credentials file is limited to the intended owner or group. |
| == Resolved issues | ||
|
|
||
| File system backups no longer create `PodVolumeBackup` CRs for excluded PVCs:: | ||
| Before this update, when performing a file system (FS) backup with `defaultVolumesToFsBackup: true` and explicitly excluding `persistentvolumeclaims` (PVCs) via `includedResources`, `PodVolumeBackup` resources were still created for these excluded PVCs. |
There was a problem hiding this comment.
| Before this update, when performing a file system (FS) backup with `defaultVolumesToFsBackup: true` and explicitly excluding `persistentvolumeclaims` (PVCs) via `includedResources`, `PodVolumeBackup` resources were still created for these excluded PVCs. | |
| Before this update, when performing a file system (FS) backup with `defaultVolumesToFsBackup: true` and explicitly excluding `persistentvolumeclaims` (PVCs) using `includedResources`, `PodVolumeBackup` resources were still created for these excluded PVCs. |
Not sure we should "via" in this context
| link:https://redhat.atlassian.net/browse/OADP-3009[OADP-3009] | ||
|
|
||
| S3 storage uses proxy values with `insecureSkipTLSVerify: "true"`:: | ||
| Before this update, when running image registry backups to S3 storage in a proxy-required environment, setting `insecureSkipTLSVerify: "true"` caused the S3 storage to ignore the configured proxy environment. As a consequence, image registry backups could fail or hang in proxy environments. With this release, the image registry backup path is updated. As a result, backups with `backupImages: true` complete successfully with both `insecureSkipTLSVerify:` set to `"true"` and `"false"`. |
There was a problem hiding this comment.
| Before this update, when running image registry backups to S3 storage in a proxy-required environment, setting `insecureSkipTLSVerify: "true"` caused the S3 storage to ignore the configured proxy environment. As a consequence, image registry backups could fail or hang in proxy environments. With this release, the image registry backup path is updated. As a result, backups with `backupImages: true` complete successfully with both `insecureSkipTLSVerify:` set to `"true"` and `"false"`. | |
| Before this update, when running image registry backups to S3 storage in a proxy-required environment, setting `insecureSkipTLSVerify: "true"` caused the system to ignore the configured proxy, leading to backups hanging or failing. With this release, the backup logic has been updated to properly respect proxy settings. As a result, backups using `backupImages: true` now complete successfully regardless of whether `insecureSkipTLSVerify` is set to "true" or "false". |
pedantic
anarnold97
left a comment
There was a problem hiding this comment.
A few suggestions but nothing that needs to be changed
Version(s):
OCP 4.14-4.18
Issue:
OADP-7566
Link to docs preview:
QE review:
Changes: