CA-427406: remove obsolete CSLG errors and fix reused error codes.#7070
CA-427406: remove obsolete CSLG errors and fix reused error codes.#7070MarkSymsCtx wants to merge 1 commit into
Conversation
It seems that after StorageLink was removed from XenServer that a number of the failure codes previously used by StorageLink have been reused for new error message which results in some confusing errors. Such as getting ``` The user name is missing ``` instead of the correct ``` Timed out waiting for storage device to appear ``` resulting from a iSCSI device not appearing within a timeout period. Signed-off-by: Mark Syms <mark.syms@citrix.com>
lindig
left a comment
lindig
left a comment
There was a problem hiding this comment.
Is this problem only present in the C# SDK but not others?
Not sure, only observed there as it was XenCenter errors that we're brought up. |
|
I can't find the keys in the other SDKs but @kc284 would know. |
| </data> | ||
| <data name="SR_BACKEND_FAILURE_431" xml:space="preserve"> | ||
| <value>Error in storage adapter communication</value> | ||
| <value>Storage multipath failure</value> |
There was a problem hiding this comment.
If the updated message is the same as in XE_SR_ERRORCODES.xml, the entry should be removed really. This file is supposed to contain only overrides, for example, when we need a string with C# formatting placeholders like blah {0} blah {1}.
One thing to note is that the build takes XE_SR_ERRORCODES.xml from the sm build result, but at some point @edwintorok added a copy in this repo, so if you are changing the sm file you probably need to copy it over the file in here to keep them up to date.
There was a problem hiding this comment.
Regarding @lindig 's question
Is this problem only present in the C# SDK but not others?
it is only the C# SDK that ships with a resx file with all the API and SM errors because it used to be needed for localisation in XenCenter. However, localisation has now been discontinued so we may not need this anymore - the overrides with the C# placeholders should probably move to XenCenter as noone says that other SDK clients want to use them in the same way as XenCenter. I'll take an action to investigate this.
4 participants
It seems that after StorageLink was removed from XenServer that a number of the failure codes previously used by StorageLink have been reused for new error message which results in some confusing errors. Such as getting
instead of the correct
resulting from a iSCSI device not appearing within a timeout period.