Crush location labels are not added for subvolumegroup and radosnamespace about rook HOT 7 CLOSED

@travisn yes these are 3 separate issues that I created to ensure that we don't miss anything but the root cause is the same we are not updating the csiConfigmap as required.

from rook.

Read Affinity in CM is not respected anymore

We no longer use CSI_ENABLE_READ_AFFINITY since we have added read affinity options per cluster. I believe we can safely remove it.

👍🏻

When we move from Host Networking to pod networking by changing CSI_ENABLE_HOST_NETWORK to false, netNamespace path is not updated for all the clusterID's

Do we actually need to add it to all cluster IDs? Currently, we only add it to the 'rook-ceph' cluster ID entry. I don't see it has an issue.

yes it need to be added to all the clusterID of specific ceph cluster or else we will have problem for radosnamespace/subvolumegroup created for that cluster.

When we switch back from Pod networking to Host networking by updating CSI_ENABLE_HOST_NETWORK to true the networkNamespaceFilePath is not removed for all the clusterID's

Currently, there is no logic in place to remove the netNamespaceFilePath when CSI_ENABLE_HOST_NETWORK is set to true.

that would be a bug in existing code :(

from rook.

when a new subvolumegroup/radosnamespace is created crushlocation is not added for all the clusterID if the readAffinity is not enabled

if CSI_ENABLE_READ_AFFINITY is set to true or false in operator configmap its having no effected. we need to remove that from CM as it is not used

I think, it should be fine right ?
if readAffinity is not enabled, there's no impact of presence or absence of crushLocationLabels or it being null.
(I agree that the entries look inconsistent though).

from rook.

when a new subvolumegroup/radosnamespace is created crushlocation is not added for all the clusterID if the readAffinity is not enabled

if CSI_ENABLE_READ_AFFINITY is set to true or false in operator configmap its having no effected. we need to remove that from CM as it is not used

I think, it should be fine right ? if readAffinity is not enabled, there's no impact of presence or absence of crushLocationLabels or it being null. (I agree that the entries look inconsistent though).

Yes it should be fine but lets keep all the data in the configmap consistent.

from rook.

Could you summarize at the top of the issue what is needed? This looks like three separate issues. Is there one root cause?

from rook.

Read Affinity in CM is not respected anymore

We no longer use CSI_ENABLE_READ_AFFINITY since we have added read affinity options per cluster. I believe we can safely remove it.

When we move from Host Networking to pod networking by changing CSI_ENABLE_HOST_NETWORK to false, netNamespace path is not updated for all the clusterID's

Do we actually need to add it to all cluster IDs? Currently, we only add it to the 'rook-ceph' cluster ID entry.
I don't see it has an issue.

When we switch back from Pod networking to Host networking by updating CSI_ENABLE_HOST_NETWORK to true the networkNamespaceFilePath is not removed for all the clusterID's

Currently, there is no logic in place to remove the netNamespaceFilePath when CSI_ENABLE_HOST_NETWORK is set to true.

from rook.

I can't speak to the nuances of how rados namespaces or cephfs subvolume groups operate, but there is definitely a bug here that affects transition to/from Multus-enabled clusters if the netNamespaceFilePath isn't being updated.

I think it probably makes sense to tackle all of these symptoms at the same time by fixing the csiConfigmap update process.

This sounds like an issue of the code that handles the confgmap not being developed to determine the best end-state, and instead only designed to handle "if this changes, then do this" logic, which (I've given a talk on this) leads to issues like this where corner cases exist. It would be good to make sure the code generates the ideal configmap from scratch with every reconcile, and then applies it with no if-then logic about config/state transitions.

from rook.