Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: PendingReleaseNotes for update netNamespaceFilePath PR #13809

Merged
merged 1 commit into from
Feb 28, 2024
Merged

doc: PendingReleaseNotes for update netNamespaceFilePath PR #13809

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion PendingReleaseNotes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,9 @@
- The removal of `CSI_ENABLE_READ_AFFINITY` option and its replacement with per-cluster
read affinity setting in cephCluster CR (CSIDriverOptions section) in [PR](https://github.com/rook/rook/pull/13665)
- Allow setting the Ceph `application` on a pool

- updating `netNamespaceFilePath` for all clusterIDs in rook-ceph-csi-config configMap in [PR](https://github.com/rook/rook/pull/13613)
- Issue: The netNamespaceFilePath isn't updated in the CSI config map for all the clusterIDs when `CSI_ENABLE_HOST_NETWORK` is set to false in `operator.yaml`
- Impact: This results in the unintended network configurations, with pods using the host networking instead of pod networking.
Comment on lines +8 to +10
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need help understanding this pending release note. This is listed as a breaking change, but there are no instructions for users to follow to keep their cluster from breaking. Is this actually a breaking change?

@Madhu-1 @iPraveenParihar @travisn

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think nothing was required from the user point and we never supported moving from multus/pod network to host networking or vice-versa, @iPraveenParihar can you please check this and confirm?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@BlaineEXE actually this was an issue that I believed users should be aware of if they were using Pod networking.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think nothing was required from the user point and we never supported moving from multus/pod network to host networking or vice-versa

I thought there was a period of time where we had CSI_ENABLE_HOST_NETWORK: false as the default value for all Rook users? Am I misremembering?

If that was the default, then we need to have supported users setting that value back to true so they could get in line with the latest recommendations.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was enabled briefly three years ago (see #8085), but I'm not sure we need to worry about that too much since it was for such a short time and users would have had serious issues if they didn't already convert back to host networking.

## Features

- Kubernetes versions **v1.24** through **v1.29** are supported.
Loading