Description of problem:
The solution that offered for Bug 1788631 added to the administration doc that the values expected would come only from the engine for ISCSI discovery and login.
The only values received from the engine would be used for the ISCSI discovery and login. If we begin the discovery with an FQDN, then the other operations will be using FQDN only. Same for IP addresses. We are using only the values that the engine returns.
Need to describe in the administration doc:
* If the customer using SDK / REST API (values received from the engine)
* If the customer using UI (values received from the engine)
* If the customer using host CLI just running iscsiadm commands (values weren't received from the engine)
Version-Release number of selected component (if applicable):
ovirt-engine-4.4.1.7-0.3.el8ev.noarch
vdsm-4.40.22-1.el8ev.x86_64
How reproducible:
100%
Actual results:
The admin guide doesn't contain that the customer should do discovery and login the same as "engine" does meaning that customers should use the same IP/FQDN used before or after the engine.
If the customers will use host CLI and run iscsiadm commands for discovery and login via RHV with the same IP/FQDN, the operation should fail as described in the bug 1788631.(https://bugzilla.redhat.com/show_bug.cgi?id=1788631)
Expected results:
The options for ISCSI discover and login should be performed in the doc as described above.
Customers can/will hit this in at 4.4 GA(using RHEL CLI/SDK scripts/ansible which is mixing IP/FQDN discovery/login requests) that worked fine in 4.3/RHEL7 as RHEL8 changed behavior.
Changing the target milestone to 4.4.1.
We should be added to admin guide for 4.4GA.
Also, we should add to docs possible results seen in QE multiple ENVs for mixing non-engine values used for the ISCSI discovery aside from login failure itself(see [1][2]).
The most common case seen multiple time at QE lab was:
After ISCSI login failure Host activation failed with "failed to setup iscsi subsystem" leaving the host in Non Operational state.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1788631#c5
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1788631#c10