Add message argument to LICENSE_CHECKOUT_ERROR #6592
Conversation
The first argument of this API error is used for error codes as defined by v6d. These product-specific error codes can be matched on by clients who know about them (e.g. XenCenter for XenServer). The new, second argument allows v6d to return an error message in English that xe can print directly, while xe remains product agnostic and does not need to know v6d's error definitions. This replaces some awkward API-message handling code in cli_operations. Signed-off-by: Rob Hoes <[email protected]>
|
@psafont please note: this includes a small change to v6_interface.ml and therefore requires an update to v6d. |
| || msg.API.message_name = fst Api_messages.v6_rejected | ||
| || msg.API.message_name = fst Api_messages.v6_comm_error | ||
| || msg.API.message_name | ||
| = fst Api_messages.v6_license_server_version_obsolete |
There was a problem hiding this comment.
If I understood this right, xe now doesn't need to know about these messages, but they still need to be exposed so clients can still react to them, is this correct?
There was a problem hiding this comment.
You mean the definitions in api_messages? I'd like to remove them as well, but I was worried about breaking the SDK.
| date *) | ||
| | License_processing_error (** License could not be processed *) | ||
| | License_checkout_error of string (** License could not be checked out *) | ||
| | License_checkout_error of string * string |
There was a problem hiding this comment.
Since this is a breaking change anyway you could also completely rename the variant to something else?
(Then you could also keep the old one for backwards compatibility if needed)
There was a problem hiding this comment.
As this is an host-internal interface, I don't think it is worth worrying about. In practice we update xapi+v6d at the same time.
The daemon has so little code this error is never used :) |
I checked the code to see whether it needed changes because of xapi-project/xen-api#6592 but it all looks good. I saw that I could make small improvements. I left some other, like code formatting out
4 participants
The first argument of this API error is used for error codes as defined by v6d. These product-specific error codes can be matched on by clients who know about them (e.g. XenCenter for XenServer).
The new, second argument allows v6d to return an error message in English that xe can print directly, while xe remains product agnostic and does not need to know v6d's error definitions. This replaces some awkward API-message handling code in cli_operations.