Description of problem: Refer to https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/3.11/html-single/operations_guide/index#replace_block Here, we are forcing the client(initiator) to discover the iscsi devices again but what happens when the app pod moves? Won't it get the old IPs and fail to mount the device? Is there a way to update the PVC/PV to make sure that the ISCSI mount plugin of Kubernetes gets the right IPs?
This is an RFE which needs thorough testing and cannot be taken during 3.11.2. However it would be good to have a draft document with the steps.
@Ratlur, I doubt if I have correctly understand the question. If your question is what happens when we do replace node and then the application pod is migrated from current node (when the replace node is done) to the other ? Will the new initiator gets new set of IP's while discovery ? Answer is yes, after replace-block volume operation is done, whether we rediscover on the same node of the new one, it is supposed that we get new set of IP's only. Hope that answers your question. Let me know, if there is anything unanswered. Thanks!
> Answer is yes, after replace-block volume operation is done, whether we > rediscover on the same node of the new one, it is supposed that we get new s/same node of the new one/same node or the new one (node)/
Prasanna In the documentation, we have steps 12,13,14 Logout of the old portal by executing the following command on the initiator: To re-discover the new node execute the following command: Login to the new portal by executing the following command: However, that is not a long term fix. Whenever that PV is mounted again either on the same node or a different one, it will refer to the portal+target IPs that are listed in the PV. We want steps that illustrate to how update the PV with new IPs.
Thanks for the clarification Talur. I got the missing piece. Leaving a needinfo on Humble, who might be able to help with the steps needed to update target portals in PV database after replace operation.
Great, dev will test if we can update the PV with new portal+target IPs values and get back to you with an update. If it is not changeable through the PV this will need to be deferred or closed.
(In reply to Prasanna Kumar Kalever from comment #13) > Thanks for the clarification Talur. I got the missing piece. Leaving a > needinfo on Humble, who might be able to help with the steps needed to > update target portals in PV database after replace operation. Unfortunately its not possible to edit PVs. Its immutable.
Based on Comment 15, I moving this bug out of 3.11.4
Anjana, ping.
wrt to comment 26 and 30, I have mentioned a preview link to be reviewed. How do we move forward on this in the context of documentation?
Just to avoid further confusion, Moving the bug back to POST, until the steps are finalized.
Please refer to preview link ( minor addition-add a new node) https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/3.11/html-single/operations_guide/index?lb_target=preview