CP-51895: Drop FCoE support when fcoe_driver does not exists #6202
Conversation
FCoE support will be removed from XS9 and dom0 will no longer provide fcoe_driver. However, XS8 still actively support it. Xapi checks the existence of fcoe_driver, and thinks all PIFs no longer support FCoE if fcoe_driver not found Signed-off-by: Lin Liu <[email protected]>
|
XS8 BST: 209859 (Dev Run) |
ocaml/xapi/xapi_pif.ml
Outdated
| | false -> | ||
| (* Does not support FCoE from XS9, presuming not in use | ||
| * Upgrade plugin will block upgrade with FCoE in use *) | ||
| () |
There was a problem hiding this comment.
We can't know if the fcoe_driver is absent intentionally or not. The original logic would raise an exception to complain the absence of the driver. But now it would pass quietly.
In other words, if the driver does not exist, but it reaches here, it would be good to let it raise the exception to expose the error.
There was a problem hiding this comment.
That is the design, e.g Xapi would permit the absence of fcoe_driver, in which case, it think current XS does not support FCoE. If the driver does not exist, it is by intention.
There is another alternative by checking Xapi_version.product_version_text_short () and handle accordingly. (only for xapi, NOT for networkd). This seems NOT work for XCP, which is the reason I did not prefer. (because we have comments In the case of XCP, all product_* fields will be blank).
@minglumlu what is the suggestion?
There was a problem hiding this comment.
The suggestion is not changing this function at all.
The caller is as the following. Is it possible that there is fcoe in PIF.capabilities while the fcoe_driver is absent intentionally? If not, then letting it go as before (raising exception) would be fine?
if Db.PIF.get_capabilities ~__context ~self |> List.mem "fcoe" then
assert_fcoe_not_in_use ~__context ~self ;
There was a problem hiding this comment.
Is it possible that there is fcoe in PIF.capabilities while the fcoe_driver is absent intentionally?
No, this should NOT be possible.
If not, then letting it go as before (raising exception) would be fine?
No, Xapi would try to initialise the capabilities during its startup, refer to fcoe-nics.md
|
Who knows more about FCoE that can confirm that this change is desirable for XS8? I'm not comfortable approving this change of behaviour in XS8, this looks like it should be only for XS9. |
This is the simplest way to keep the code compatible with XS8 and XS9. (and compatible with XCP) |
- Add logs when fcoe_driver does not exist - Use List.assoc_opt instead of try catch - Add __FUNCTION__ to the logs Signed-off-by: Lin Liu <[email protected]>
liulinC
force-pushed
the
private/linl/dev
branch
from
ee44d57 to
71c87a1
Compare
FCoE support will be removed from XS9 and dom0 will no longer provide fcoe_driver. However, XS8 still actively support it.
Xapi checks the existence of fcoe_driver, and thinks all PIFs no longer support FCoE if fcoe_driver not found