[Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class

Einav Cohen ecohen at redhat.com
Mon Nov 11 15:18:12 UTC 2013


> ----- Original Message -----
> From: "Shubhendu Tripathi" <shtripat at redhat.com>
> Sent: Saturday, November 9, 2013 4:07:44 AM
> 
> On 11/06/2013 07:40 PM, Einav Cohen wrote:
> >> ----- Original Message -----
> >> From: "Alexander Wels" <awels at redhat.com>
> >> Sent: Wednesday, November 6, 2013 8:28:13 AM
> >>
> >> Looking at the code, if you start the error message with a $ it will not
> >> do
> >> the . to _ replacement. Not sure if your error message will now simply
> >> start
> >> with a $, but it is worth a try I guess.
> > AFAIK: the '$' prefix is for variable-value message.
> > e.g. if you have a message "cannot run VM ${vm-name}" and another one
> > "$vm-name vm1",
> > then their combination would eventually yield "cannot run VM vm1".
> > Also, I think that messages that begin with "$" cannot be displayed when
> > they
> > are on their own.
> > i.e. if you will get message "$vm-name vm1" 'alone', nothing will
> > eventually be displayed.
> > but, as I mentioned, if you will get message "$vm-name vm1" along with
> > message "cannot run
> > VM ${vm-name}", eventually "cannot run VM vm1" will be displayed.
> >
> > I think that the replacement of "." to "_" should be done only if the
> > message
> > represents a *key* in the relevant resource (VdsmErrors in this case).
> > but if the message is not a key, and would be displayed as-is, on "." to
> > "_" replacement
> > should take place.
> > adding Derez for his thoughts (I think that he changed something around it
> > a while ago).
> There is an upstream patch according to Einav's suggestion above.
> http://gerrit.ovirt.org/#/c/21083/

Many thanks, Shubhendu.
@Derez - any chance that you can take a look (as you probably understand best 
this particular code/logic)?

> 
> >
> >> On Wednesday, November 06, 2013 03:37:34 PM Shubhendu Tripathi wrote:
> >>> Hi,
> >>>
> >>> In the case of Gluster, as there are no one to one mappings available
> >>> for all the error messages from Gluster, we set the error in the
> >>> VdcFault object as NULL.
> >>> We also populate the actual error from the Gluster as error message in
> >>> the fault object.
> >>>
> >>> /getReturnValue().getExecuteFailedMessages().add(error);//
> >>> //getReturnValue().getFault().setMessage(error);//
> >>> //getReturnValue().getFault().setError(null);/
> >>>
> >>> Because of above settings and the below code snippet in /Frontend.java/
> >>> class the error message as is gets displayed on the error dialog -
> >>> /
> >>> //public String translateVdcFault(final VdcFault fault) {//
> >>> //        return
> >>> getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() ==
> >>> null//
> >>> //                ? fault.getMessage() : fault.getError().toString());//
> >>> //}//
> >>> /
> >>> Well and good till now !!
> >>>
> >>> But while translation of the error messages, all the occurrences of "."
> >>> get replaced with "_".
> >>> This causes an issue for the gluster errors. If the error message sent
> >>> from gluster has "."s (say IP Address of a host or FQDN for a host),
> >>> that also gets replaced with "_" and the error message does not look
> >>> correct.
> >>>
> >>> Request your suggestion for handling such a case.
> >>>
> >>> *PS: *One thing I can think of is, introducing a flag called
> >>> /isExternalError/ in /VdcFault/ class to identify if the source of the
> >>> fault is external. From Gluster we would set the flag as /true/, and
> >>> while replacement of "." with "_", if the flag is set it will not do the
> >>> replacements.
> >>>
> >>> Regards,
> >>> Shubhendu
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> >
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 



More information about the Engine-devel mailing list