From shtripat at redhat.com Wed Nov 6 05:07:38 2013 Content-Type: multipart/mixed; boundary="===============5478388967859804737==" MIME-Version: 1.0 From: Shubhendu Tripathi To: devel at ovirt.org Subject: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class Date: Wed, 06 Nov 2013 15:37:34 +0530 Message-ID: <527A14E6.8010809@redhat.com> --===============5478388967859804737== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------020507040501040703080208 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit 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() =3D=3D = 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 --------------020507040501040703080208 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit 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.jav= a class the error message as is gets displayed on the error dialog -

public String translateVdcFault(final VdcFault fault) {=
        return getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() =3D=3D null
          &n= bsp;     ? 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 is= ExternalError 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
--------------020507040501040703080208-- --===============5478388967859804737== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wMjA1MDcwNDA1MDEwNDA3MDMwODAyMDgKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PUlTTy04ODU5LTE7IGZvcm1hdD1mbG93ZWQKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog N2JpdAoKSGksCgpJbiB0aGUgY2FzZSBvZiBHbHVzdGVyLCBhcyB0aGVyZSBhcmUgbm8gb25lIHRv IG9uZSBtYXBwaW5ncyBhdmFpbGFibGUgCmZvciBhbGwgdGhlIGVycm9yIG1lc3NhZ2VzIGZyb20g R2x1c3Rlciwgd2Ugc2V0IHRoZSBlcnJvciBpbiB0aGUgClZkY0ZhdWx0IG9iamVjdCBhcyBOVUxM LgpXZSBhbHNvIHBvcHVsYXRlIHRoZSBhY3R1YWwgZXJyb3IgZnJvbSB0aGUgR2x1c3RlciBhcyBl cnJvciBtZXNzYWdlIGluIAp0aGUgZmF1bHQgb2JqZWN0LgoKL2dldFJldHVyblZhbHVlKCkuZ2V0 RXhlY3V0ZUZhaWxlZE1lc3NhZ2VzKCkuYWRkKGVycm9yKTsvLwovL2dldFJldHVyblZhbHVlKCku Z2V0RmF1bHQoKS5zZXRNZXNzYWdlKGVycm9yKTsvLwovL2dldFJldHVyblZhbHVlKCkuZ2V0RmF1 bHQoKS5zZXRFcnJvcihudWxsKTsvCgpCZWNhdXNlIG9mIGFib3ZlIHNldHRpbmdzIGFuZCB0aGUg YmVsb3cgY29kZSBzbmlwcGV0IGluIC9Gcm9udGVuZC5qYXZhLyAKY2xhc3MgdGhlIGVycm9yIG1l c3NhZ2UgYXMgaXMgZ2V0cyBkaXNwbGF5ZWQgb24gdGhlIGVycm9yIGRpYWxvZyAtCi8KLy9wdWJs aWMgU3RyaW5nIHRyYW5zbGF0ZVZkY0ZhdWx0KGZpbmFsIFZkY0ZhdWx0IGZhdWx0KSB7Ly8KLy8g ICAgICAgIHJldHVybiAKZ2V0VmRzbUVycm9yc1RyYW5zbGF0b3IoKS5UcmFuc2xhdGVFcnJvclRl eHRTaW5nbGUoZmF1bHQuZ2V0RXJyb3IoKSA9PSAKbnVsbC8vCi8vICAgICAgICAgICAgICAgID8g ZmF1bHQuZ2V0TWVzc2FnZSgpIDogZmF1bHQuZ2V0RXJyb3IoKS50b1N0cmluZygpKTsvLwovL30v LwovCldlbGwgYW5kIGdvb2QgdGlsbCBub3cgISEKCkJ1dCB3aGlsZSB0cmFuc2xhdGlvbiBvZiB0 aGUgZXJyb3IgbWVzc2FnZXMsIGFsbCB0aGUgb2NjdXJyZW5jZXMgb2YgIi4iIApnZXQgcmVwbGFj ZWQgd2l0aCAiXyIuClRoaXMgY2F1c2VzIGFuIGlzc3VlIGZvciB0aGUgZ2x1c3RlciBlcnJvcnMu IElmIHRoZSBlcnJvciBtZXNzYWdlIHNlbnQgCmZyb20gZ2x1c3RlciBoYXMgIi4icyAoc2F5IElQ IEFkZHJlc3Mgb2YgYSBob3N0IG9yIEZRRE4gZm9yIGEgaG9zdCksIAp0aGF0IGFsc28gZ2V0cyBy ZXBsYWNlZCB3aXRoICJfIiBhbmQgdGhlIGVycm9yIG1lc3NhZ2UgZG9lcyBub3QgbG9vayAKY29y cmVjdC4KClJlcXVlc3QgeW91ciBzdWdnZXN0aW9uIGZvciBoYW5kbGluZyBzdWNoIGEgY2FzZS4K CipQUzogKk9uZSB0aGluZyBJIGNhbiB0aGluayBvZiBpcywgaW50cm9kdWNpbmcgYSBmbGFnIGNh bGxlZCAKL2lzRXh0ZXJuYWxFcnJvci8gaW4gL1ZkY0ZhdWx0LyBjbGFzcyB0byBpZGVudGlmeSBp ZiB0aGUgc291cmNlIG9mIHRoZSAKZmF1bHQgaXMgZXh0ZXJuYWwuIEZyb20gR2x1c3RlciB3ZSB3 b3VsZCBzZXQgdGhlIGZsYWcgYXMgL3RydWUvLCBhbmQgCndoaWxlIHJlcGxhY2VtZW50IG9mICIu IiB3aXRoICJfIiwgaWYgdGhlIGZsYWcgaXMgc2V0IGl0IHdpbGwgbm90IGRvIHRoZSAKcmVwbGFj ZW1lbnRzLgoKUmVnYXJkcywKU2h1YmhlbmR1CgotLS0tLS0tLS0tLS0tLTAyMDUwNzA0MDUwMTA0 MDcwMzA4MDIwOApDb250ZW50LVR5cGU6IHRleHQvaHRtbDsgY2hhcnNldD1JU08tODg1OS0xCkNv bnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQKCjxodG1sPgogIDxoZWFkPgoKICAgIDxtZXRh IGh0dHAtZXF1aXY9ImNvbnRlbnQtdHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PUlT Ty04ODU5LTEiPgogIDwvaGVhZD4KICA8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAw MDAwIj4KICAgIEhpLDxicj4KICAgIDxicj4KICAgIEluIHRoZSBjYXNlIG9mIEdsdXN0ZXIsIGFz IHRoZXJlIGFyZSBubyBvbmUgdG8gb25lIG1hcHBpbmdzCiAgICBhdmFpbGFibGUgZm9yIGFsbCB0 aGUgZXJyb3IgbWVzc2FnZXMgZnJvbSBHbHVzdGVyLCB3ZSBzZXQgdGhlIGVycm9yCiAgICBpbiB0 aGUgVmRjRmF1bHQgb2JqZWN0IGFzIE5VTEwuPGJyPgogICAgV2UgYWxzbyBwb3B1bGF0ZSB0aGUg YWN0dWFsIGVycm9yIGZyb20gdGhlIEdsdXN0ZXIgYXMgZXJyb3IgbWVzc2FnZQogICAgaW4gdGhl IGZhdWx0IG9iamVjdC48YnI+CiAgICA8YnI+CiAgICA8Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGk+ Z2V0UmV0dXJuVmFsdWUoKS5nZXRFeGVjdXRlRmFpbGVkTWVzc2FnZXMoKS5hZGQoZXJyb3IpOzwv aT48aT48YnI+CiAgICAgIDwvaT48aT5nZXRSZXR1cm5WYWx1ZSgpLmdldEZhdWx0KCkuc2V0TWVz c2FnZShlcnJvcik7PC9pPjxpPjxicj4KICAgICAgPC9pPjxpPmdldFJldHVyblZhbHVlKCkuZ2V0 RmF1bHQoKS5zZXRFcnJvcihudWxsKTs8L2k+PC9mb250Pjxicj4KICAgIDxicj4KICAgIEJlY2F1 c2Ugb2YgYWJvdmUgc2V0dGluZ3MgYW5kIHRoZSBiZWxvdyBjb2RlIHNuaXBwZXQgaW4gPGk+RnJv bnRlbmQuamF2YTwvaT4KICAgIGNsYXNzIHRoZSBlcnJvciBtZXNzYWdlIGFzIGlzIGdldHMgZGlz cGxheWVkIG9uIHRoZSBlcnJvciBkaWFsb2cgLTxicj4KICAgIDxmb250IGNvbG9yPSIjMDAwMDk5 Ij48aT48YnI+CiAgICAgIDwvaT48aT5wdWJsaWMgU3RyaW5nIHRyYW5zbGF0ZVZkY0ZhdWx0KGZp bmFsIFZkY0ZhdWx0IGZhdWx0KSB7PC9pPjxpPjxicj4KICAgICAgPC9pPjxpPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXR1cm4KICAgICAgICBnZXRWZHNtRXJy b3JzVHJhbnNsYXRvcigpLlRyYW5zbGF0ZUVycm9yVGV4dFNpbmdsZShmYXVsdC5nZXRFcnJvcigp CiAgICAgICAgPT0gbnVsbDwvaT48aT48YnI+CiAgICAgIDwvaT48aT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPyBmYXVsdC5nZXRNZXNzYWdlKCkgOgogICAgICAgIGZhdWx0Lmdl dEVycm9yKCkudG9TdHJpbmcoKSk7PC9pPjxpPjxicj4KICAgICAgPC9pPjxpPn08L2k+PGk+PGJy PgogICAgICA8L2k+PC9mb250Pjxicj4KICAgIFdlbGwgYW5kIGdvb2QgdGlsbCBub3cgISE8YnI+ CiAgICA8YnI+CiAgICBCdXQgd2hpbGUgdHJhbnNsYXRpb24gb2YgdGhlIGVycm9yIG1lc3NhZ2Vz LCBhbGwgdGhlIG9jY3VycmVuY2VzIG9mCiAgICAiLiIgZ2V0IHJlcGxhY2VkIHdpdGggIl8iLjxi cj4KICAgIFRoaXMgY2F1c2VzIGFuIGlzc3VlIGZvciB0aGUgZ2x1c3RlciBlcnJvcnMuIElmIHRo ZSBlcnJvciBtZXNzYWdlCiAgICBzZW50IGZyb20gZ2x1c3RlciBoYXMgIi4icyAoc2F5IElQIEFk ZHJlc3Mgb2YgYSBob3N0IG9yIEZRRE4gZm9yIGEKICAgIGhvc3QpLCB0aGF0IGFsc28gZ2V0cyBy ZXBsYWNlZCB3aXRoICJfIiBhbmQgdGhlIGVycm9yIG1lc3NhZ2UgZG9lcwogICAgbm90IGxvb2sg Y29ycmVjdC48YnI+CiAgICA8YnI+CiAgICBSZXF1ZXN0IHlvdXIgc3VnZ2VzdGlvbiBmb3IgaGFu ZGxpbmcgc3VjaCBhIGNhc2UuPGJyPgogICAgPGJyPgogICAgPGI+UFM6IDwvYj5PbmUgdGhpbmcg SSBjYW4gdGhpbmsgb2YgaXMsIGludHJvZHVjaW5nIGEgZmxhZyBjYWxsZWQgPGk+aXNFeHRlcm5h bEVycm9yPC9pPgogICAgaW4gPGk+VmRjRmF1bHQ8L2k+IGNsYXNzIHRvIGlkZW50aWZ5IGlmIHRo ZSBzb3VyY2Ugb2YgdGhlIGZhdWx0IGlzCiAgICBleHRlcm5hbC4gRnJvbSBHbHVzdGVyIHdlIHdv dWxkIHNldCB0aGUgZmxhZyBhcyA8aT50cnVlPC9pPiwgYW5kCiAgICB3aGlsZSByZXBsYWNlbWVu dCBvZiAiLiIgd2l0aCAiXyIsIGlmIHRoZSBmbGFnIGlzIHNldCBpdCB3aWxsIG5vdCBkbwogICAg dGhlIHJlcGxhY2VtZW50cy48YnI+CiAgICA8YnI+CiAgICBSZWdhcmRzLDxicj4KICAgIFNodWJo ZW5kdSA8YnI+CiAgPC9ib2R5Pgo8L2h0bWw+CgotLS0tLS0tLS0tLS0tLTAyMDUwNzA0MDUwMTA0 MDcwMzA4MDIwOC0tCg== --===============5478388967859804737==-- From awels at redhat.com Wed Nov 6 08:37:55 2013 Content-Type: multipart/mixed; boundary="===============7439871278528440406==" MIME-Version: 1.0 From: Alexander Wels To: devel at ovirt.org Subject: Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class Date: Wed, 06 Nov 2013 08:28:13 -0500 Message-ID: <2115335.RGeYIF2D09@awels> In-Reply-To: 527A14E6.8010809@redhat.com --===============7439871278528440406== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 star= t = with a $, but it is worth a try I guess. 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() =3D= =3D > 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 --===============7439871278528440406==-- From ecohen at redhat.com Wed Nov 6 09:10:16 2013 Content-Type: multipart/mixed; boundary="===============2237385313268171975==" MIME-Version: 1.0 From: Einav Cohen To: devel at ovirt.org Subject: Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class Date: Wed, 06 Nov 2013 09:10:09 -0500 Message-ID: <1082228530.20856483.1383747009016.JavaMail.root@redhat.com> In-Reply-To: 2115335.RGeYIF2D09@awels --===============2237385313268171975== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > ----- Original Message ----- > From: "Alexander Wels" > 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 st= art > 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 th= ey = are on their own. i.e. if you will get message "$vm-name vm1" 'alone', nothing will eventuall= y be displayed. = but, as I mentioned, if you will get message "$vm-name vm1" along with mess= age "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 messa= ge = 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). > = > 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() =3D= =3D > > 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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >=20 --===============2237385313268171975==-- From ecohen at redhat.com Wed Nov 6 09:11:58 2013 Content-Type: multipart/mixed; boundary="===============8490862181204499256==" MIME-Version: 1.0 From: Einav Cohen To: devel at ovirt.org Subject: Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class Date: Wed, 06 Nov 2013 09:11:53 -0500 Message-ID: <1395352625.20859205.1383747113095.JavaMail.root@redhat.com> In-Reply-To: 1082228530.20856483.1383747009016.JavaMail.root@redhat.com --===============8490862181204499256== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > but if the message is not a key, and would be displayed as-is, on "." to = "_" > replacement should take place. on -> no* > ----- Original Message ----- > From: "Einav Cohen" > Sent: Wednesday, November 6, 2013 9:10:09 AM > = > > ----- Original Message ----- > > From: "Alexander Wels" > > Sent: Wednesday, November 6, 2013 8:28:13 AM > > = > > Looking at the code, if you start the error message with a $ it will no= t 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 eventua= lly > 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 mes= sage > 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 i= t a > while ago). > = > > = > > 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.jav= a/ > > > class the error message as is gets displayed on the error dialog - > > > / > > > //public String translateVdcFault(final VdcFault fault) {// > > > // return > > > getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() = =3D=3D > > > 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(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > = > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >=20 --===============8490862181204499256==-- From derez at redhat.com Wed Nov 6 09:13:32 2013 Content-Type: multipart/mixed; boundary="===============7391169138164455517==" MIME-Version: 1.0 From: Daniel Erez To: devel at ovirt.org Subject: Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class Date: Wed, 06 Nov 2013 09:13:30 -0500 Message-ID: <1626430710.26900628.1383747210835.JavaMail.root@redhat.com> In-Reply-To: 527A14E6.8010809@redhat.com --===============7391169138164455517== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Shubhendu Tripathi" > To: derez(a)redhat.com, "engine-devel" > Cc: "Dusmant Pati" > Sent: Wednesday, November 6, 2013 12:07:34 PM > Subject: IMP: Regarding an issue while translating the error messages for= gluster using ErrorTranslator class > = > 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() =3D= =3D > 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. This mechanism of replacing [1] has been introduced to allow proper message translation when retrieving a message key that contains dots. E.g. AppErrors.properties -> VALIDATION.ROLES.NAME.MAX is translated to VALIDATION_ROLES_NAME_MAX in AppErrors.java interface (as interface signatures cannot contain dots. Note that this process shouldn't address the message; i.e. only the key is examined for dots. As you've mentioned VdsmErrorsTranslator I guess there's an issue only when translating VdsmErrors messages. Can you please send an example of a message usage? (and maybe try the same message using AppErrors instead) [1] ErrorTranslator -> translateErrorTextSingle() > = > 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 >=20 --===============7391169138164455517==-- From shtripat at redhat.com Wed Nov 6 09:32:07 2013 Content-Type: multipart/mixed; boundary="===============8909997894603869198==" MIME-Version: 1.0 From: Shubhendu Tripathi To: devel at ovirt.org Subject: Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class Date: Wed, 06 Nov 2013 20:01:52 +0530 Message-ID: <527A52D8.9040700@redhat.com> In-Reply-To: 1626430710.26900628.1383747210835.JavaMail.root@redhat.com --===============8909997894603869198== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------080803010008020502090907 Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed Content-Transfer-Encoding: 7bit On 11/06/2013 07:43 PM, Daniel Erez wrote: > > ----- Original Message ----- >> From: "Shubhendu Tripathi" >> To: derez(a)redhat.com, "engine-devel" >> Cc: "Dusmant Pati" >> Sent: Wednesday, November 6, 2013 12:07:34 PM >> Subject: IMP: Regarding an issue while translating the error messages fo= r gluster using ErrorTranslator class >> >> 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() =3D= =3D >> 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. > This mechanism of replacing [1] has been introduced to allow proper > message translation when retrieving a message key that contains dots. > E.g. AppErrors.properties -> VALIDATION.ROLES.NAME.MAX is translated > to VALIDATION_ROLES_NAME_MAX in AppErrors.java interface (as interface > signatures cannot contain dots. Note that this process shouldn't > address the message; i.e. only the key is examined for dots. > > As you've mentioned VdsmErrorsTranslator I guess there's an issue > only when translating VdsmErrors messages. > Can you please send an example of a message usage? One example of the error message which is shown on the dialog after = translation is as below - /"Error while executin action Create Gluster Volume: Volume create = failed error: Staging failed on //*10_70_43_122_*//Error: /export/vol1-a = is already part of a volume"/ If you see the highlighted portion not only the dots in IP address but = also the full stop is changed to "_". > (and maybe try the same message using AppErrors instead) There are no one to one mapping of these messages in AppErrors as they = arise randomly, so in such cases we throw the VDSM error message as is = on the dialog. > > [1] ErrorTranslator -> translateErrorTextSingle() > >> 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 >> --------------080803010008020502090907 Content-Type: text/html; charset=3DUTF-8 Content-Transfer-Encoding: 7bit
On 11/06/2013 07:43 PM, Daniel Erez wrote:

----- Original Message -----

From: "Shubhendu Tripathi" <shtripat(a)redhat.com&g=
t;
To: derez(a)redhat.com, "engine-devel" <engine-devel(a)ovirt.org><=
/a>
Cc: "Dusmant Pati" <dpati(a)redhat.com>
Sent: Wednesday, November 6, 2013 12:07:34 PM
Subject: IMP: Regarding an issue while translating the error messages for g=
luster using ErrorTranslator class

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() =3D=3D
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.

This mechanism of replacing [1] has been introduced to allow proper
message translation when retrieving a message key that contains dots.
E.g. AppErrors.properties -> VALIDATION.ROLES.NAME.MAX is translated
to VALIDATION_ROLES_NAME_MAX in AppErrors.java interface (as interface
signatures cannot contain dots. Note that this process shouldn't
address the message; i.e. only the key is examined for dots.

As you've mentioned VdsmErrorsTranslator I guess there's an issue
only when translating VdsmErrors messages.
Can you please send an example of a message usage?
One example of the error message which is shown on the dialog after translation is as below -

"Error while executin action Create Gluster Volume: Volume create failed error: Staging failed on 10_= 70_43_122_ Error: /export/vol1-a is already part of a volume"

If you see the highlighted portion not only the dots in IP address but also the full stop is changed to "_".
(and maybe try the same message using AppErrors instead)
There are no one to one mapping of these messages in AppErrors as they arise randomly, so in such cases we throw the VDSM error message as is on the dialog.

[1] ErrorTranslator -> translateErrorTextSingle()


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

--------------080803010008020502090907-- --===============8909997894603869198== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wODA4MDMwMTAwMDgwMjA1MDIwOTA5MDcKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PVVURi04OyBmb3JtYXQ9Zmxvd2VkCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQK Ck9uIDExLzA2LzIwMTMgMDc6NDMgUE0sIERhbmllbCBFcmV6IHdyb3RlOgo+Cj4gLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLQo+PiBGcm9tOiAiU2h1YmhlbmR1IFRyaXBhdGhpIiA8c2h0cmlw YXRAcmVkaGF0LmNvbT4KPj4gVG86IGRlcmV6QHJlZGhhdC5jb20sICJlbmdpbmUtZGV2ZWwiIDxl bmdpbmUtZGV2ZWxAb3ZpcnQub3JnPgo+PiBDYzogIkR1c21hbnQgUGF0aSIgPGRwYXRpQHJlZGhh dC5jb20+Cj4+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgNiwgMjAxMyAxMjowNzozNCBQTQo+ PiBTdWJqZWN0OiBJTVA6IFJlZ2FyZGluZyBhbiBpc3N1ZSB3aGlsZSB0cmFuc2xhdGluZyB0aGUg ZXJyb3IgbWVzc2FnZXMgZm9yIGdsdXN0ZXIgdXNpbmcgRXJyb3JUcmFuc2xhdG9yIGNsYXNzCj4+ Cj4+IEhpLAo+Pgo+PiBJbiB0aGUgY2FzZSBvZiBHbHVzdGVyLCBhcyB0aGVyZSBhcmUgbm8gb25l IHRvIG9uZSBtYXBwaW5ncyBhdmFpbGFibGUKPj4gZm9yIGFsbCB0aGUgZXJyb3IgbWVzc2FnZXMg ZnJvbSBHbHVzdGVyLCB3ZSBzZXQgdGhlIGVycm9yIGluIHRoZQo+PiBWZGNGYXVsdCBvYmplY3Qg YXMgTlVMTC4KPj4gV2UgYWxzbyBwb3B1bGF0ZSB0aGUgYWN0dWFsIGVycm9yIGZyb20gdGhlIEds dXN0ZXIgYXMgZXJyb3IgbWVzc2FnZSBpbgo+PiB0aGUgZmF1bHQgb2JqZWN0Lgo+Pgo+PiAvZ2V0 UmV0dXJuVmFsdWUoKS5nZXRFeGVjdXRlRmFpbGVkTWVzc2FnZXMoKS5hZGQoZXJyb3IpOy8vCj4+ IC8vZ2V0UmV0dXJuVmFsdWUoKS5nZXRGYXVsdCgpLnNldE1lc3NhZ2UoZXJyb3IpOy8vCj4+IC8v Z2V0UmV0dXJuVmFsdWUoKS5nZXRGYXVsdCgpLnNldEVycm9yKG51bGwpOy8KPj4KPj4gQmVjYXVz ZSBvZiBhYm92ZSBzZXR0aW5ncyBhbmQgdGhlIGJlbG93IGNvZGUgc25pcHBldCBpbiAvRnJvbnRl bmQuamF2YS8KPj4gY2xhc3MgdGhlIGVycm9yIG1lc3NhZ2UgYXMgaXMgZ2V0cyBkaXNwbGF5ZWQg b24gdGhlIGVycm9yIGRpYWxvZyAtCj4+IC8KPj4gLy9wdWJsaWMgU3RyaW5nIHRyYW5zbGF0ZVZk Y0ZhdWx0KGZpbmFsIFZkY0ZhdWx0IGZhdWx0KSB7Ly8KPj4gLy8gICAgICAgIHJldHVybgo+PiBn ZXRWZHNtRXJyb3JzVHJhbnNsYXRvcigpLlRyYW5zbGF0ZUVycm9yVGV4dFNpbmdsZShmYXVsdC5n ZXRFcnJvcigpID09Cj4+IG51bGwvLwo+PiAvLyAgICAgICAgICAgICAgICA/IGZhdWx0LmdldE1l c3NhZ2UoKSA6IGZhdWx0LmdldEVycm9yKCkudG9TdHJpbmcoKSk7Ly8KPj4gLy99Ly8KPj4gLwo+ PiBXZWxsIGFuZCBnb29kIHRpbGwgbm93ICEhCj4+Cj4+IEJ1dCB3aGlsZSB0cmFuc2xhdGlvbiBv ZiB0aGUgZXJyb3IgbWVzc2FnZXMsIGFsbCB0aGUgb2NjdXJyZW5jZXMgb2YgIi4iCj4+IGdldCBy ZXBsYWNlZCB3aXRoICJfIi4KPj4gVGhpcyBjYXVzZXMgYW4gaXNzdWUgZm9yIHRoZSBnbHVzdGVy IGVycm9ycy4gSWYgdGhlIGVycm9yIG1lc3NhZ2Ugc2VudAo+PiBmcm9tIGdsdXN0ZXIgaGFzICIu InMgKHNheSBJUCBBZGRyZXNzIG9mIGEgaG9zdCBvciBGUUROIGZvciBhIGhvc3QpLAo+PiB0aGF0 IGFsc28gZ2V0cyByZXBsYWNlZCB3aXRoICJfIiBhbmQgdGhlIGVycm9yIG1lc3NhZ2UgZG9lcyBu b3QgbG9vawo+PiBjb3JyZWN0Lgo+IFRoaXMgbWVjaGFuaXNtIG9mIHJlcGxhY2luZyBbMV0gaGFz IGJlZW4gaW50cm9kdWNlZCB0byBhbGxvdyBwcm9wZXIKPiBtZXNzYWdlIHRyYW5zbGF0aW9uIHdo ZW4gcmV0cmlldmluZyBhIG1lc3NhZ2Uga2V5IHRoYXQgY29udGFpbnMgZG90cy4KPiBFLmcuIEFw cEVycm9ycy5wcm9wZXJ0aWVzIC0+IFZBTElEQVRJT04uUk9MRVMuTkFNRS5NQVggaXMgdHJhbnNs YXRlZAo+IHRvIFZBTElEQVRJT05fUk9MRVNfTkFNRV9NQVggaW4gQXBwRXJyb3JzLmphdmEgaW50 ZXJmYWNlIChhcyBpbnRlcmZhY2UKPiBzaWduYXR1cmVzIGNhbm5vdCBjb250YWluIGRvdHMuIE5v dGUgdGhhdCB0aGlzIHByb2Nlc3Mgc2hvdWxkbid0Cj4gYWRkcmVzcyB0aGUgbWVzc2FnZTsgaS5l LiBvbmx5IHRoZSBrZXkgaXMgZXhhbWluZWQgZm9yIGRvdHMuCj4KPiBBcyB5b3UndmUgbWVudGlv bmVkIFZkc21FcnJvcnNUcmFuc2xhdG9yIEkgZ3Vlc3MgdGhlcmUncyBhbiBpc3N1ZQo+IG9ubHkg d2hlbiB0cmFuc2xhdGluZyBWZHNtRXJyb3JzIG1lc3NhZ2VzLgo+IENhbiB5b3UgcGxlYXNlIHNl bmQgYW4gZXhhbXBsZSBvZiBhIG1lc3NhZ2UgdXNhZ2U/Ck9uZSBleGFtcGxlIG9mIHRoZSBlcnJv ciBtZXNzYWdlIHdoaWNoIGlzIHNob3duIG9uIHRoZSBkaWFsb2cgYWZ0ZXIgCnRyYW5zbGF0aW9u IGlzIGFzIGJlbG93IC0KCi8iRXJyb3Igd2hpbGUgZXhlY3V0aW4gYWN0aW9uIENyZWF0ZSBHbHVz dGVyIFZvbHVtZTogVm9sdW1lIGNyZWF0ZSAKZmFpbGVkIGVycm9yOiBTdGFnaW5nIGZhaWxlZCBv biAvLyoxMF83MF80M18xMjJfKi8vRXJyb3I6IC9leHBvcnQvdm9sMS1hIAppcyBhbHJlYWR5IHBh cnQgb2YgYSB2b2x1bWUiLwoKSWYgeW91IHNlZSB0aGUgaGlnaGxpZ2h0ZWQgcG9ydGlvbiBub3Qg b25seSB0aGUgZG90cyBpbiBJUCBhZGRyZXNzIGJ1dCAKYWxzbyB0aGUgZnVsbCBzdG9wIGlzIGNo YW5nZWQgdG8gIl8iLgo+IChhbmQgbWF5YmUgdHJ5IHRoZSBzYW1lIG1lc3NhZ2UgdXNpbmcgQXBw RXJyb3JzIGluc3RlYWQpClRoZXJlIGFyZSBubyBvbmUgdG8gb25lIG1hcHBpbmcgb2YgdGhlc2Ug bWVzc2FnZXMgaW4gQXBwRXJyb3JzIGFzIHRoZXkgCmFyaXNlIHJhbmRvbWx5LCBzbyBpbiBzdWNo IGNhc2VzIHdlIHRocm93IHRoZSBWRFNNIGVycm9yIG1lc3NhZ2UgYXMgaXMgCm9uIHRoZSBkaWFs b2cuCj4KPiBbMV0gRXJyb3JUcmFuc2xhdG9yIC0+IHRyYW5zbGF0ZUVycm9yVGV4dFNpbmdsZSgp Cj4KPj4gUmVxdWVzdCB5b3VyIHN1Z2dlc3Rpb24gZm9yIGhhbmRsaW5nIHN1Y2ggYSBjYXNlLgo+ Pgo+PiAqUFM6ICpPbmUgdGhpbmcgSSBjYW4gdGhpbmsgb2YgaXMsIGludHJvZHVjaW5nIGEgZmxh ZyBjYWxsZWQKPj4gL2lzRXh0ZXJuYWxFcnJvci8gaW4gL1ZkY0ZhdWx0LyBjbGFzcyB0byBpZGVu dGlmeSBpZiB0aGUgc291cmNlIG9mIHRoZQo+PiBmYXVsdCBpcyBleHRlcm5hbC4gRnJvbSBHbHVz dGVyIHdlIHdvdWxkIHNldCB0aGUgZmxhZyBhcyAvdHJ1ZS8sIGFuZAo+PiB3aGlsZSByZXBsYWNl bWVudCBvZiAiLiIgd2l0aCAiXyIsIGlmIHRoZSBmbGFnIGlzIHNldCBpdCB3aWxsIG5vdCBkbyB0 aGUKPj4gcmVwbGFjZW1lbnRzLgo+Pgo+PiBSZWdhcmRzLAo+PiBTaHViaGVuZHUKPj4KCgotLS0t LS0tLS0tLS0tLTA4MDgwMzAxMDAwODAyMDUwMjA5MDkwNwpDb250ZW50LVR5cGU6IHRleHQvaHRt bDsgY2hhcnNldD1VVEYtOApDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0Cgo8aHRtbD4K ICA8aGVhZD4KICAgIDxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCIgaHR0 cC1lcXVpdj0iQ29udGVudC1UeXBlIj4KICA8L2hlYWQ+CiAgPGJvZHkgYmdjb2xvcj0iI0ZGRkZG RiIgdGV4dD0iIzAwMDAwMCI+CiAgICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDEx LzA2LzIwMTMgMDc6NDMgUE0sIERhbmllbCBFcmV6CiAgICAgIHdyb3RlOjxicj4KICAgIDwvZGl2 PgogICAgPGJsb2NrcXVvdGUKICAgICAgY2l0ZT0ibWlkOjE2MjY0MzA3MTAuMjY5MDA2MjguMTM4 Mzc0NzIxMDgzNS5KYXZhTWFpbC5yb290QHJlZGhhdC5jb20iCiAgICAgIHR5cGU9ImNpdGUiPgog ICAgICA8cHJlIHdyYXA9IiI+CgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCjwvcHJlPgog ICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4KICAgICAgICA8cHJlIHdyYXA9IiI+RnJvbTog IlNodWJoZW5kdSBUcmlwYXRoaSIgPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJl Zj0ibWFpbHRvOnNodHJpcGF0QHJlZGhhdC5jb20iPiZsdDtzaHRyaXBhdEByZWRoYXQuY29tJmd0 OzwvYT4KVG86IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0 bzpkZXJlekByZWRoYXQuY29tIj5kZXJlekByZWRoYXQuY29tPC9hPiwgImVuZ2luZS1kZXZlbCIg PGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmVuZ2luZS1kZXZl bEBvdmlydC5vcmciPiZsdDtlbmdpbmUtZGV2ZWxAb3ZpcnQub3JnJmd0OzwvYT4KQ2M6ICJEdXNt YW50IFBhdGkiIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpk cGF0aUByZWRoYXQuY29tIj4mbHQ7ZHBhdGlAcmVkaGF0LmNvbSZndDs8L2E+ClNlbnQ6IFdlZG5l c2RheSwgTm92ZW1iZXIgNiwgMjAxMyAxMjowNzozNCBQTQpTdWJqZWN0OiBJTVA6IFJlZ2FyZGlu ZyBhbiBpc3N1ZSB3aGlsZSB0cmFuc2xhdGluZyB0aGUgZXJyb3IgbWVzc2FnZXMgZm9yIGdsdXN0 ZXIgdXNpbmcgRXJyb3JUcmFuc2xhdG9yIGNsYXNzCgpIaSwKCkluIHRoZSBjYXNlIG9mIEdsdXN0 ZXIsIGFzIHRoZXJlIGFyZSBubyBvbmUgdG8gb25lIG1hcHBpbmdzIGF2YWlsYWJsZQpmb3IgYWxs IHRoZSBlcnJvciBtZXNzYWdlcyBmcm9tIEdsdXN0ZXIsIHdlIHNldCB0aGUgZXJyb3IgaW4gdGhl ClZkY0ZhdWx0IG9iamVjdCBhcyBOVUxMLgpXZSBhbHNvIHBvcHVsYXRlIHRoZSBhY3R1YWwgZXJy b3IgZnJvbSB0aGUgR2x1c3RlciBhcyBlcnJvciBtZXNzYWdlIGluCnRoZSBmYXVsdCBvYmplY3Qu CgovZ2V0UmV0dXJuVmFsdWUoKS5nZXRFeGVjdXRlRmFpbGVkTWVzc2FnZXMoKS5hZGQoZXJyb3Ip Oy8vCi8vZ2V0UmV0dXJuVmFsdWUoKS5nZXRGYXVsdCgpLnNldE1lc3NhZ2UoZXJyb3IpOy8vCi8v Z2V0UmV0dXJuVmFsdWUoKS5nZXRGYXVsdCgpLnNldEVycm9yKG51bGwpOy8KCkJlY2F1c2Ugb2Yg YWJvdmUgc2V0dGluZ3MgYW5kIHRoZSBiZWxvdyBjb2RlIHNuaXBwZXQgaW4gL0Zyb250ZW5kLmph dmEvCmNsYXNzIHRoZSBlcnJvciBtZXNzYWdlIGFzIGlzIGdldHMgZGlzcGxheWVkIG9uIHRoZSBl cnJvciBkaWFsb2cgLQovCi8vcHVibGljIFN0cmluZyB0cmFuc2xhdGVWZGNGYXVsdChmaW5hbCBW ZGNGYXVsdCBmYXVsdCkgey8vCi8vICAgICAgICByZXR1cm4KZ2V0VmRzbUVycm9yc1RyYW5zbGF0 b3IoKS5UcmFuc2xhdGVFcnJvclRleHRTaW5nbGUoZmF1bHQuZ2V0RXJyb3IoKSA9PQpudWxsLy8K Ly8gICAgICAgICAgICAgICAgPyBmYXVsdC5nZXRNZXNzYWdlKCkgOiBmYXVsdC5nZXRFcnJvcigp LnRvU3RyaW5nKCkpOy8vCi8vfS8vCi8KV2VsbCBhbmQgZ29vZCB0aWxsIG5vdyAhIQoKQnV0IHdo aWxlIHRyYW5zbGF0aW9uIG9mIHRoZSBlcnJvciBtZXNzYWdlcywgYWxsIHRoZSBvY2N1cnJlbmNl cyBvZiAiLiIKZ2V0IHJlcGxhY2VkIHdpdGggIl8iLgpUaGlzIGNhdXNlcyBhbiBpc3N1ZSBmb3Ig dGhlIGdsdXN0ZXIgZXJyb3JzLiBJZiB0aGUgZXJyb3IgbWVzc2FnZSBzZW50CmZyb20gZ2x1c3Rl ciBoYXMgIi4icyAoc2F5IElQIEFkZHJlc3Mgb2YgYSBob3N0IG9yIEZRRE4gZm9yIGEgaG9zdCks CnRoYXQgYWxzbyBnZXRzIHJlcGxhY2VkIHdpdGggIl8iIGFuZCB0aGUgZXJyb3IgbWVzc2FnZSBk b2VzIG5vdCBsb29rCmNvcnJlY3QuCjwvcHJlPgogICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgIDxw cmUgd3JhcD0iIj4KVGhpcyBtZWNoYW5pc20gb2YgcmVwbGFjaW5nIFsxXSBoYXMgYmVlbiBpbnRy b2R1Y2VkIHRvIGFsbG93IHByb3BlcgptZXNzYWdlIHRyYW5zbGF0aW9uIHdoZW4gcmV0cmlldmlu ZyBhIG1lc3NhZ2Uga2V5IHRoYXQgY29udGFpbnMgZG90cy4KRS5nLiBBcHBFcnJvcnMucHJvcGVy dGllcyAtJmd0OyBWQUxJREFUSU9OLlJPTEVTLk5BTUUuTUFYIGlzIHRyYW5zbGF0ZWQKdG8gVkFM SURBVElPTl9ST0xFU19OQU1FX01BWCBpbiBBcHBFcnJvcnMuamF2YSBpbnRlcmZhY2UgKGFzIGlu dGVyZmFjZQpzaWduYXR1cmVzIGNhbm5vdCBjb250YWluIGRvdHMuIE5vdGUgdGhhdCB0aGlzIHBy b2Nlc3Mgc2hvdWxkbid0CmFkZHJlc3MgdGhlIG1lc3NhZ2U7IGkuZS4gb25seSB0aGUga2V5IGlz IGV4YW1pbmVkIGZvciBkb3RzLgoKQXMgeW91J3ZlIG1lbnRpb25lZCBWZHNtRXJyb3JzVHJhbnNs YXRvciBJIGd1ZXNzIHRoZXJlJ3MgYW4gaXNzdWUKb25seSB3aGVuIHRyYW5zbGF0aW5nIFZkc21F cnJvcnMgbWVzc2FnZXMuCkNhbiB5b3UgcGxlYXNlIHNlbmQgYW4gZXhhbXBsZSBvZiBhIG1lc3Nh Z2UgdXNhZ2U/PC9wcmU+CiAgICA8L2Jsb2NrcXVvdGU+CiAgICBPbmUgZXhhbXBsZSBvZiB0aGUg ZXJyb3IgbWVzc2FnZSB3aGljaCBpcyBzaG93biBvbiB0aGUgZGlhbG9nIGFmdGVyCiAgICB0cmFu c2xhdGlvbiBpcyBhcyBiZWxvdyAtPGJyPgogICAgPGJyPgogICAgPGk+IkVycm9yIHdoaWxlIGV4 ZWN1dGluIGFjdGlvbiBDcmVhdGUgR2x1c3RlciBWb2x1bWU6IFZvbHVtZSBjcmVhdGUKICAgICAg ZmFpbGVkIGVycm9yOiBTdGFnaW5nIGZhaWxlZCBvbiA8L2k+PGk+PGZvbnQgY29sb3I9IiNmZjAw MDAiPjxiPjEwXzcwXzQzXzEyMl88L2I+PC9mb250PjwvaT48aT4KICAgICAgRXJyb3I6IC9leHBv cnQvdm9sMS1hIGlzIGFscmVhZHkgcGFydCBvZiBhIHZvbHVtZSI8L2k+PGJyPgogICAgPGJyPgog ICAgSWYgeW91IHNlZSB0aGUgaGlnaGxpZ2h0ZWQgcG9ydGlvbiBub3Qgb25seSB0aGUgZG90cyBp biBJUCBhZGRyZXNzCiAgICBidXQgYWxzbyB0aGUgZnVsbCBzdG9wIGlzIGNoYW5nZWQgdG8gIl8i Ljxicj4KICAgIDxibG9ja3F1b3RlCiAgICAgIGNpdGU9Im1pZDoxNjI2NDMwNzEwLjI2OTAwNjI4 LjEzODM3NDcyMTA4MzUuSmF2YU1haWwucm9vdEByZWRoYXQuY29tIgogICAgICB0eXBlPSJjaXRl Ij4KICAgICAgPHByZSB3cmFwPSIiPgooYW5kIG1heWJlIHRyeSB0aGUgc2FtZSBtZXNzYWdlIHVz aW5nIEFwcEVycm9ycyBpbnN0ZWFkKTwvcHJlPgogICAgPC9ibG9ja3F1b3RlPgogICAgVGhlcmUg YXJlIG5vIG9uZSB0byBvbmUgbWFwcGluZyBvZiB0aGVzZSBtZXNzYWdlcyBpbiBBcHBFcnJvcnMg YXMKICAgIHRoZXkgYXJpc2UgcmFuZG9tbHksIHNvIGluIHN1Y2ggY2FzZXMgd2UgdGhyb3cgdGhl IFZEU00gZXJyb3IKICAgIG1lc3NhZ2UgYXMgaXMgb24gdGhlIGRpYWxvZy48YnI+CiAgICA8Ymxv Y2txdW90ZQogICAgICBjaXRlPSJtaWQ6MTYyNjQzMDcxMC4yNjkwMDYyOC4xMzgzNzQ3MjEwODM1 LkphdmFNYWlsLnJvb3RAcmVkaGF0LmNvbSIKICAgICAgdHlwZT0iY2l0ZSI+CiAgICAgIDxwcmUg d3JhcD0iIj4KClsxXSBFcnJvclRyYW5zbGF0b3IgLSZndDsgdHJhbnNsYXRlRXJyb3JUZXh0U2lu Z2xlKCkKCjwvcHJlPgogICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4KICAgICAgICA8cHJl IHdyYXA9IiI+ClJlcXVlc3QgeW91ciBzdWdnZXN0aW9uIGZvciBoYW5kbGluZyBzdWNoIGEgY2Fz ZS4KCipQUzogKk9uZSB0aGluZyBJIGNhbiB0aGluayBvZiBpcywgaW50cm9kdWNpbmcgYSBmbGFn IGNhbGxlZAovaXNFeHRlcm5hbEVycm9yLyBpbiAvVmRjRmF1bHQvIGNsYXNzIHRvIGlkZW50aWZ5 IGlmIHRoZSBzb3VyY2Ugb2YgdGhlCmZhdWx0IGlzIGV4dGVybmFsLiBGcm9tIEdsdXN0ZXIgd2Ug d291bGQgc2V0IHRoZSBmbGFnIGFzIC90cnVlLywgYW5kCndoaWxlIHJlcGxhY2VtZW50IG9mICIu IiB3aXRoICJfIiwgaWYgdGhlIGZsYWcgaXMgc2V0IGl0IHdpbGwgbm90IGRvIHRoZQpyZXBsYWNl bWVudHMuCgpSZWdhcmRzLApTaHViaGVuZHUKCjwvcHJlPgogICAgICA8L2Jsb2NrcXVvdGU+CiAg ICA8L2Jsb2NrcXVvdGU+CiAgICA8YnI+CiAgPC9ib2R5Pgo8L2h0bWw+CgotLS0tLS0tLS0tLS0t LTA4MDgwMzAxMDAwODAyMDUwMjA5MDkwNy0tCg== --===============8909997894603869198==-- From shtripat at redhat.com Wed Nov 6 09:33:57 2013 Content-Type: multipart/mixed; boundary="===============8460992017451095094==" MIME-Version: 1.0 From: Shubhendu Tripathi To: devel at ovirt.org Subject: Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class Date: Wed, 06 Nov 2013 20:03:53 +0530 Message-ID: <527A5351.7060203@redhat.com> In-Reply-To: 1395352625.20859205.1383747113095.JavaMail.root@redhat.com --===============8460992017451095094== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 11/06/2013 07:41 PM, Einav Cohen wrote: >> but if the message is not a key, and would be displayed as-is, on "." to= "_" >> replacement should take place. > on -> no* This solution looks fine. If the error message is not found in the map, = we can revert back to original message which has the "."s. Request comments from others as well. > >> ----- Original Message ----- >> From: "Einav Cohen" >> Sent: Wednesday, November 6, 2013 9:10:09 AM >> >>> ----- Original Message ----- >>> From: "Alexander Wels" >>> Sent: Wednesday, November 6, 2013 8:28:13 AM >>> >>> Looking at the code, if you start the error message with a $ it will no= t 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 eventu= ally >> 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 me= ssage >> 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). >> >>> 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() = =3D=3D >>>> 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 t= he >>>> replacements. >>>> >>>> Regards, >>>> Shubhendu >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > --===============8460992017451095094==-- From derez at redhat.com Wed Nov 6 10:59:27 2013 Content-Type: multipart/mixed; boundary="===============1317107113536898504==" MIME-Version: 1.0 From: Daniel Erez To: devel at ovirt.org Subject: Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class Date: Wed, 06 Nov 2013 10:59:22 -0500 Message-ID: <1514562916.26958300.1383753561998.JavaMail.root@redhat.com> In-Reply-To: 527A52D8.9040700@redhat.com --===============1317107113536898504== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Shubhendu Tripathi" > To: "Daniel Erez" > Cc: "engine-devel" , "Dusmant Pati" > Sent: Wednesday, November 6, 2013 4:31:52 PM > Subject: Re: IMP: Regarding an issue while translating the error messages= for gluster using ErrorTranslator class > = > On 11/06/2013 07:43 PM, Daniel Erez wrote: > > > > ----- Original Message ----- > >> From: "Shubhendu Tripathi" > >> To: derez(a)redhat.com, "engine-devel" > >> Cc: "Dusmant Pati" > >> Sent: Wednesday, November 6, 2013 12:07:34 PM > >> Subject: IMP: Regarding an issue while translating the error messages = for > >> gluster using ErrorTranslator class > >> > >> 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() = =3D=3D > >> 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. > > This mechanism of replacing [1] has been introduced to allow proper > > message translation when retrieving a message key that contains dots. > > E.g. AppErrors.properties -> VALIDATION.ROLES.NAME.MAX is translated > > to VALIDATION_ROLES_NAME_MAX in AppErrors.java interface (as interface > > signatures cannot contain dots. Note that this process shouldn't > > address the message; i.e. only the key is examined for dots. > > > > As you've mentioned VdsmErrorsTranslator I guess there's an issue > > only when translating VdsmErrors messages. > > Can you please send an example of a message usage? > One example of the error message which is shown on the dialog after > translation is as below - > = > /"Error while executin action Create Gluster Volume: Volume create > failed error: Staging failed on //*10_70_43_122_*//Error: /export/vol1-a > is already part of a volume"/ What are the keys that been sent from the engine (i.e. the message before t= ranslation)? > = > If you see the highlighted portion not only the dots in IP address but > also the full stop is changed to "_". > > (and maybe try the same message using AppErrors instead) > There are no one to one mapping of these messages in AppErrors as they > arise randomly, so in such cases we throw the VDSM error message as is > on the dialog. > > > > [1] ErrorTranslator -> translateErrorTextSingle() > > > >> 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 t= he > >> replacements. > >> > >> Regards, > >> Shubhendu > >> > = >=20 --===============1317107113536898504==-- From shtripat at redhat.com Thu Nov 7 01:32:04 2013 Content-Type: multipart/mixed; boundary="===============8621158009880736323==" MIME-Version: 1.0 From: Shubhendu Tripathi To: devel at ovirt.org Subject: Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class Date: Thu, 07 Nov 2013 12:01:57 +0530 Message-ID: <527B33DD.1000405@redhat.com> In-Reply-To: 1514562916.26958300.1383753561998.JavaMail.root@redhat.com --===============8621158009880736323== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------040302010801050202030308 Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed Content-Transfer-Encoding: 7bit On 11/06/2013 09:29 PM, Daniel Erez wrote: > > ----- Original Message ----- >> From: "Shubhendu Tripathi" >> To: "Daniel Erez" >> Cc: "engine-devel" , "Dusmant Pati" >> Sent: Wednesday, November 6, 2013 4:31:52 PM >> Subject: Re: IMP: Regarding an issue while translating the error message= s for gluster using ErrorTranslator class >> >> On 11/06/2013 07:43 PM, Daniel Erez wrote: >>> ----- Original Message ----- >>>> From: "Shubhendu Tripathi" >>>> To: derez(a)redhat.com, "engine-devel" >>>> Cc: "Dusmant Pati" >>>> Sent: Wednesday, November 6, 2013 12:07:34 PM >>>> Subject: IMP: Regarding an issue while translating the error messages = for >>>> gluster using ErrorTranslator class >>>> >>>> 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() = =3D=3D >>>> 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. >>> This mechanism of replacing [1] has been introduced to allow proper >>> message translation when retrieving a message key that contains dots. >>> E.g. AppErrors.properties -> VALIDATION.ROLES.NAME.MAX is translated >>> to VALIDATION_ROLES_NAME_MAX in AppErrors.java interface (as interface >>> signatures cannot contain dots. Note that this process shouldn't >>> address the message; i.e. only the key is examined for dots. >>> >>> As you've mentioned VdsmErrorsTranslator I guess there's an issue >>> only when translating VdsmErrors messages. >>> Can you please send an example of a message usage? >> One example of the error message which is shown on the dialog after >> translation is as below - >> >> /"Error while executin action Create Gluster Volume: Volume create >> failed error: Staging failed on //*10_70_43_122_*//Error: /export/vol1-a >> is already part of a volume"/ > What are the keys that been sent from the engine (i.e. the message before= translation)? We set message code as NULL and error message is set as is whatever is = received from VDSM. Message contains dots (".") as part of it. Code snippet is shown below - /getReturnValue().getExecuteFailedMessages().add(error); getReturnValue().getFault().setMessage(error); getReturnValue().getFault().setError(null);/ >> If you see the highlighted portion not only the dots in IP address but >> also the full stop is changed to "_". >>> (and maybe try the same message using AppErrors instead) >> There are no one to one mapping of these messages in AppErrors as they >> arise randomly, so in such cases we throw the VDSM error message as is >> on the dialog. >>> [1] ErrorTranslator -> translateErrorTextSingle() >>> >>>> 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 t= he >>>> replacements. >>>> >>>> Regards, >>>> Shubhendu >>>> >> --------------040302010801050202030308 Content-Type: text/html; charset=3DUTF-8 Content-Transfer-Encoding: 7bit
On 11/06/2013 09:29 PM, Daniel Erez wrote:

----- Original Message -----

From: "Shubhendu Tripathi" <shtripat(a)redhat.com&g=
t;
To: "Daniel Erez" <derez(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Dusmant Pati" <dpa=
ti(a)redhat.com>
Sent: Wednesday, November 6, 2013 4:31:52 PM
Subject: Re: IMP: Regarding an issue while translating the error messages f=
or gluster using ErrorTranslator class

On 11/06/2013 07:43 PM, Daniel Erez wrote:

----- Original Message -----

From: "Shubhendu Tripathi" <shtripat(a)redhat.c=
om>
To: derez(a)redhat.com, "engine-devel" <engine-devel(a)ovirt.org><=
/a>
Cc: "Dusmant Pati" <dpati(a)redhat.com>
Sent: Wednesday, November 6, 2013 12:07:34 PM
Subject: IMP: Regarding an issue while translating the error messages for
gluster using ErrorTranslator class

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() =3D=3D
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.

This mechanism of replacing [1] has been introduce=
d to allow proper
message translation when retrieving a message key that contains dots.
E.g. AppErrors.properties -> VALIDATION.ROLES.NAME.MAX is translated
to VALIDATION_ROLES_NAME_MAX in AppErrors.java interface (as interface
signatures cannot contain dots. Note that this process shouldn't
address the message; i.e. only the key is examined for dots.

As you've mentioned VdsmErrorsTranslator I guess there's an issue
only when translating VdsmErrors messages.
Can you please send an example of a message usage?

One example of the error message which is shown on t=
he dialog after
translation is as below -

/"Error while executin action Create Gluster Volume: Volume create
failed error: Staging failed on //*10_70_43_122_*//Error: /export/vol1-a
is already part of a volume"/

What are the keys that been sent from the engine (i.e. the message before t=
ranslation)?
We set message code as NULL and error message is set as is whatever is received from VDSM. Message contains dots (".") as part of it.
Code snippet is shown below -
getReturnValue().getExecuteFa=
iledMessages().add(error);
getReturnValue().getFault().setMessage(error);
getReturnValue().getFault().setError(null);<=
/i>

If you see the highlighted portion not only the dots in IP address but
also the full stop is changed to "_".

(and maybe try the same message using AppErrors in=
stead)

There are no one to one mapping of these messages in=
 AppErrors as they
arise randomly, so in such cases we throw the VDSM error message as is
on the dialog.

[1] ErrorTranslator -> translateErrorTextSingle()


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

--------------040302010801050202030308-- --===============8621158009880736323== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wNDAzMDIwMTA4MDEwNTAyMDIwMzAzMDgKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PVVURi04OyBmb3JtYXQ9Zmxvd2VkCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQK Ck9uIDExLzA2LzIwMTMgMDk6MjkgUE0sIERhbmllbCBFcmV6IHdyb3RlOgo+Cj4gLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLQo+PiBGcm9tOiAiU2h1YmhlbmR1IFRyaXBhdGhpIiA8c2h0cmlw YXRAcmVkaGF0LmNvbT4KPj4gVG86ICJEYW5pZWwgRXJleiIgPGRlcmV6QHJlZGhhdC5jb20+Cj4+ IENjOiAiZW5naW5lLWRldmVsIiA8ZW5naW5lLWRldmVsQG92aXJ0Lm9yZz4sICJEdXNtYW50IFBh dGkiIDxkcGF0aUByZWRoYXQuY29tPgo+PiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDYsIDIw MTMgNDozMTo1MiBQTQo+PiBTdWJqZWN0OiBSZTogSU1QOiBSZWdhcmRpbmcgYW4gaXNzdWUgd2hp bGUgdHJhbnNsYXRpbmcgdGhlIGVycm9yIG1lc3NhZ2VzIGZvciBnbHVzdGVyIHVzaW5nIEVycm9y VHJhbnNsYXRvciBjbGFzcwo+Pgo+PiBPbiAxMS8wNi8yMDEzIDA3OjQzIFBNLCBEYW5pZWwgRXJl eiB3cm90ZToKPj4+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPj4+PiBGcm9tOiAiU2h1 YmhlbmR1IFRyaXBhdGhpIiA8c2h0cmlwYXRAcmVkaGF0LmNvbT4KPj4+PiBUbzogZGVyZXpAcmVk aGF0LmNvbSwgImVuZ2luZS1kZXZlbCIgPGVuZ2luZS1kZXZlbEBvdmlydC5vcmc+Cj4+Pj4gQ2M6 ICJEdXNtYW50IFBhdGkiIDxkcGF0aUByZWRoYXQuY29tPgo+Pj4+IFNlbnQ6IFdlZG5lc2RheSwg Tm92ZW1iZXIgNiwgMjAxMyAxMjowNzozNCBQTQo+Pj4+IFN1YmplY3Q6IElNUDogUmVnYXJkaW5n IGFuIGlzc3VlIHdoaWxlIHRyYW5zbGF0aW5nIHRoZSBlcnJvciBtZXNzYWdlcyBmb3IKPj4+PiBn bHVzdGVyIHVzaW5nIEVycm9yVHJhbnNsYXRvciBjbGFzcwo+Pj4+Cj4+Pj4gSGksCj4+Pj4KPj4+ PiBJbiB0aGUgY2FzZSBvZiBHbHVzdGVyLCBhcyB0aGVyZSBhcmUgbm8gb25lIHRvIG9uZSBtYXBw aW5ncyBhdmFpbGFibGUKPj4+PiBmb3IgYWxsIHRoZSBlcnJvciBtZXNzYWdlcyBmcm9tIEdsdXN0 ZXIsIHdlIHNldCB0aGUgZXJyb3IgaW4gdGhlCj4+Pj4gVmRjRmF1bHQgb2JqZWN0IGFzIE5VTEwu Cj4+Pj4gV2UgYWxzbyBwb3B1bGF0ZSB0aGUgYWN0dWFsIGVycm9yIGZyb20gdGhlIEdsdXN0ZXIg YXMgZXJyb3IgbWVzc2FnZSBpbgo+Pj4+IHRoZSBmYXVsdCBvYmplY3QuCj4+Pj4KPj4+PiAvZ2V0 UmV0dXJuVmFsdWUoKS5nZXRFeGVjdXRlRmFpbGVkTWVzc2FnZXMoKS5hZGQoZXJyb3IpOy8vCj4+ Pj4gLy9nZXRSZXR1cm5WYWx1ZSgpLmdldEZhdWx0KCkuc2V0TWVzc2FnZShlcnJvcik7Ly8KPj4+ PiAvL2dldFJldHVyblZhbHVlKCkuZ2V0RmF1bHQoKS5zZXRFcnJvcihudWxsKTsvCj4+Pj4KPj4+ PiBCZWNhdXNlIG9mIGFib3ZlIHNldHRpbmdzIGFuZCB0aGUgYmVsb3cgY29kZSBzbmlwcGV0IGlu IC9Gcm9udGVuZC5qYXZhLwo+Pj4+IGNsYXNzIHRoZSBlcnJvciBtZXNzYWdlIGFzIGlzIGdldHMg ZGlzcGxheWVkIG9uIHRoZSBlcnJvciBkaWFsb2cgLQo+Pj4+IC8KPj4+PiAvL3B1YmxpYyBTdHJp bmcgdHJhbnNsYXRlVmRjRmF1bHQoZmluYWwgVmRjRmF1bHQgZmF1bHQpIHsvLwo+Pj4+IC8vICAg ICAgICByZXR1cm4KPj4+PiBnZXRWZHNtRXJyb3JzVHJhbnNsYXRvcigpLlRyYW5zbGF0ZUVycm9y VGV4dFNpbmdsZShmYXVsdC5nZXRFcnJvcigpID09Cj4+Pj4gbnVsbC8vCj4+Pj4gLy8gICAgICAg ICAgICAgICAgPyBmYXVsdC5nZXRNZXNzYWdlKCkgOiBmYXVsdC5nZXRFcnJvcigpLnRvU3RyaW5n KCkpOy8vCj4+Pj4gLy99Ly8KPj4+PiAvCj4+Pj4gV2VsbCBhbmQgZ29vZCB0aWxsIG5vdyAhIQo+ Pj4+Cj4+Pj4gQnV0IHdoaWxlIHRyYW5zbGF0aW9uIG9mIHRoZSBlcnJvciBtZXNzYWdlcywgYWxs IHRoZSBvY2N1cnJlbmNlcyBvZiAiLiIKPj4+PiBnZXQgcmVwbGFjZWQgd2l0aCAiXyIuCj4+Pj4g VGhpcyBjYXVzZXMgYW4gaXNzdWUgZm9yIHRoZSBnbHVzdGVyIGVycm9ycy4gSWYgdGhlIGVycm9y IG1lc3NhZ2Ugc2VudAo+Pj4+IGZyb20gZ2x1c3RlciBoYXMgIi4icyAoc2F5IElQIEFkZHJlc3Mg b2YgYSBob3N0IG9yIEZRRE4gZm9yIGEgaG9zdCksCj4+Pj4gdGhhdCBhbHNvIGdldHMgcmVwbGFj ZWQgd2l0aCAiXyIgYW5kIHRoZSBlcnJvciBtZXNzYWdlIGRvZXMgbm90IGxvb2sKPj4+PiBjb3Jy ZWN0Lgo+Pj4gVGhpcyBtZWNoYW5pc20gb2YgcmVwbGFjaW5nIFsxXSBoYXMgYmVlbiBpbnRyb2R1 Y2VkIHRvIGFsbG93IHByb3Blcgo+Pj4gbWVzc2FnZSB0cmFuc2xhdGlvbiB3aGVuIHJldHJpZXZp bmcgYSBtZXNzYWdlIGtleSB0aGF0IGNvbnRhaW5zIGRvdHMuCj4+PiBFLmcuIEFwcEVycm9ycy5w cm9wZXJ0aWVzIC0+IFZBTElEQVRJT04uUk9MRVMuTkFNRS5NQVggaXMgdHJhbnNsYXRlZAo+Pj4g dG8gVkFMSURBVElPTl9ST0xFU19OQU1FX01BWCBpbiBBcHBFcnJvcnMuamF2YSBpbnRlcmZhY2Ug KGFzIGludGVyZmFjZQo+Pj4gc2lnbmF0dXJlcyBjYW5ub3QgY29udGFpbiBkb3RzLiBOb3RlIHRo YXQgdGhpcyBwcm9jZXNzIHNob3VsZG4ndAo+Pj4gYWRkcmVzcyB0aGUgbWVzc2FnZTsgaS5lLiBv bmx5IHRoZSBrZXkgaXMgZXhhbWluZWQgZm9yIGRvdHMuCj4+Pgo+Pj4gQXMgeW91J3ZlIG1lbnRp b25lZCBWZHNtRXJyb3JzVHJhbnNsYXRvciBJIGd1ZXNzIHRoZXJlJ3MgYW4gaXNzdWUKPj4+IG9u bHkgd2hlbiB0cmFuc2xhdGluZyBWZHNtRXJyb3JzIG1lc3NhZ2VzLgo+Pj4gQ2FuIHlvdSBwbGVh c2Ugc2VuZCBhbiBleGFtcGxlIG9mIGEgbWVzc2FnZSB1c2FnZT8KPj4gT25lIGV4YW1wbGUgb2Yg dGhlIGVycm9yIG1lc3NhZ2Ugd2hpY2ggaXMgc2hvd24gb24gdGhlIGRpYWxvZyBhZnRlcgo+PiB0 cmFuc2xhdGlvbiBpcyBhcyBiZWxvdyAtCj4+Cj4+IC8iRXJyb3Igd2hpbGUgZXhlY3V0aW4gYWN0 aW9uIENyZWF0ZSBHbHVzdGVyIFZvbHVtZTogVm9sdW1lIGNyZWF0ZQo+PiBmYWlsZWQgZXJyb3I6 IFN0YWdpbmcgZmFpbGVkIG9uIC8vKjEwXzcwXzQzXzEyMl8qLy9FcnJvcjogL2V4cG9ydC92b2wx LWEKPj4gaXMgYWxyZWFkeSBwYXJ0IG9mIGEgdm9sdW1lIi8KPiBXaGF0IGFyZSB0aGUga2V5cyB0 aGF0IGJlZW4gc2VudCBmcm9tIHRoZSBlbmdpbmUgKGkuZS4gdGhlIG1lc3NhZ2UgYmVmb3JlIHRy YW5zbGF0aW9uKT8KV2Ugc2V0IG1lc3NhZ2UgY29kZSBhcyBOVUxMIGFuZCBlcnJvciBtZXNzYWdl IGlzIHNldCBhcyBpcyB3aGF0ZXZlciBpcyAKcmVjZWl2ZWQgZnJvbSBWRFNNLiBNZXNzYWdlIGNv bnRhaW5zIGRvdHMgKCIuIikgYXMgcGFydCBvZiBpdC4KQ29kZSBzbmlwcGV0IGlzIHNob3duIGJl bG93IC0KCi9nZXRSZXR1cm5WYWx1ZSgpLmdldEV4ZWN1dGVGYWlsZWRNZXNzYWdlcygpLmFkZChl cnJvcik7CmdldFJldHVyblZhbHVlKCkuZ2V0RmF1bHQoKS5zZXRNZXNzYWdlKGVycm9yKTsKZ2V0 UmV0dXJuVmFsdWUoKS5nZXRGYXVsdCgpLnNldEVycm9yKG51bGwpOy8KCgo+PiBJZiB5b3Ugc2Vl IHRoZSBoaWdobGlnaHRlZCBwb3J0aW9uIG5vdCBvbmx5IHRoZSBkb3RzIGluIElQIGFkZHJlc3Mg YnV0Cj4+IGFsc28gdGhlIGZ1bGwgc3RvcCBpcyBjaGFuZ2VkIHRvICJfIi4KPj4+IChhbmQgbWF5 YmUgdHJ5IHRoZSBzYW1lIG1lc3NhZ2UgdXNpbmcgQXBwRXJyb3JzIGluc3RlYWQpCj4+IFRoZXJl IGFyZSBubyBvbmUgdG8gb25lIG1hcHBpbmcgb2YgdGhlc2UgbWVzc2FnZXMgaW4gQXBwRXJyb3Jz IGFzIHRoZXkKPj4gYXJpc2UgcmFuZG9tbHksIHNvIGluIHN1Y2ggY2FzZXMgd2UgdGhyb3cgdGhl IFZEU00gZXJyb3IgbWVzc2FnZSBhcyBpcwo+PiBvbiB0aGUgZGlhbG9nLgo+Pj4gWzFdIEVycm9y VHJhbnNsYXRvciAtPiB0cmFuc2xhdGVFcnJvclRleHRTaW5nbGUoKQo+Pj4KPj4+PiBSZXF1ZXN0 IHlvdXIgc3VnZ2VzdGlvbiBmb3IgaGFuZGxpbmcgc3VjaCBhIGNhc2UuCj4+Pj4KPj4+PiAqUFM6 ICpPbmUgdGhpbmcgSSBjYW4gdGhpbmsgb2YgaXMsIGludHJvZHVjaW5nIGEgZmxhZyBjYWxsZWQK Pj4+PiAvaXNFeHRlcm5hbEVycm9yLyBpbiAvVmRjRmF1bHQvIGNsYXNzIHRvIGlkZW50aWZ5IGlm IHRoZSBzb3VyY2Ugb2YgdGhlCj4+Pj4gZmF1bHQgaXMgZXh0ZXJuYWwuIEZyb20gR2x1c3RlciB3 ZSB3b3VsZCBzZXQgdGhlIGZsYWcgYXMgL3RydWUvLCBhbmQKPj4+PiB3aGlsZSByZXBsYWNlbWVu dCBvZiAiLiIgd2l0aCAiXyIsIGlmIHRoZSBmbGFnIGlzIHNldCBpdCB3aWxsIG5vdCBkbyB0aGUK Pj4+PiByZXBsYWNlbWVudHMuCj4+Pj4KPj4+PiBSZWdhcmRzLAo+Pj4+IFNodWJoZW5kdQo+Pj4+ Cj4+CgoKLS0tLS0tLS0tLS0tLS0wNDAzMDIwMTA4MDEwNTAyMDIwMzAzMDgKQ29udGVudC1UeXBl OiB0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogN2Jp dAoKPGh0bWw+CiAgPGhlYWQ+CiAgICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9 VVRGLTgiIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSI+CiAgPC9oZWFkPgogIDxib2R5IGJnY29s b3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPgogICAgPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJl Zml4Ij5PbiAxMS8wNi8yMDEzIDA5OjI5IFBNLCBEYW5pZWwgRXJlegogICAgICB3cm90ZTo8YnI+ CiAgICA8L2Rpdj4KICAgIDxibG9ja3F1b3RlCiAgICAgIGNpdGU9Im1pZDoxNTE0NTYyOTE2LjI2 OTU4MzAwLjEzODM3NTM1NjE5OTguSmF2YU1haWwucm9vdEByZWRoYXQuY29tIgogICAgICB0eXBl PSJjaXRlIj4KICAgICAgPHByZSB3cmFwPSIiPgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LQo8L3ByZT4KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+CiAgICAgICAgPHByZSB3cmFw PSIiPkZyb206ICJTaHViaGVuZHUgVHJpcGF0aGkiIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZj MjM5NkUiIGhyZWY9Im1haWx0bzpzaHRyaXBhdEByZWRoYXQuY29tIj4mbHQ7c2h0cmlwYXRAcmVk aGF0LmNvbSZndDs8L2E+ClRvOiAiRGFuaWVsIEVyZXoiIDxhIGNsYXNzPSJtb3otdHh0LWxpbmst cmZjMjM5NkUiIGhyZWY9Im1haWx0bzpkZXJlekByZWRoYXQuY29tIj4mbHQ7ZGVyZXpAcmVkaGF0 LmNvbSZndDs8L2E+CkNjOiAiZW5naW5lLWRldmVsIiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJm YzIzOTZFIiBocmVmPSJtYWlsdG86ZW5naW5lLWRldmVsQG92aXJ0Lm9yZyI+Jmx0O2VuZ2luZS1k ZXZlbEBvdmlydC5vcmcmZ3Q7PC9hPiwgIkR1c21hbnQgUGF0aSIgPGEgY2xhc3M9Im1vei10eHQt bGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmRwYXRpQHJlZGhhdC5jb20iPiZsdDtkcGF0aUBy ZWRoYXQuY29tJmd0OzwvYT4KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciA2LCAyMDEzIDQ6MzE6 NTIgUE0KU3ViamVjdDogUmU6IElNUDogUmVnYXJkaW5nIGFuIGlzc3VlIHdoaWxlIHRyYW5zbGF0 aW5nIHRoZSBlcnJvciBtZXNzYWdlcyBmb3IgZ2x1c3RlciB1c2luZyBFcnJvclRyYW5zbGF0b3Ig Y2xhc3MKCk9uIDExLzA2LzIwMTMgMDc6NDMgUE0sIERhbmllbCBFcmV6IHdyb3RlOgo8L3ByZT4K ICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4KICAgICAgICAgIDxwcmUgd3JhcD0iIj4K LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo8L3ByZT4KICAgICAgICAgIDxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPgogICAgICAgICAgICA8cHJlIHdyYXA9IiI+RnJvbTogIlNodWJoZW5kdSBU cmlwYXRoaSIgPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOnNo dHJpcGF0QHJlZGhhdC5jb20iPiZsdDtzaHRyaXBhdEByZWRoYXQuY29tJmd0OzwvYT4KVG86IDxh IGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpkZXJlekByZWRo YXQuY29tIj5kZXJlekByZWRoYXQuY29tPC9hPiwgImVuZ2luZS1kZXZlbCIgPGEgY2xhc3M9Im1v ei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmVuZ2luZS1kZXZlbEBvdmlydC5vcmci PiZsdDtlbmdpbmUtZGV2ZWxAb3ZpcnQub3JnJmd0OzwvYT4KQ2M6ICJEdXNtYW50IFBhdGkiIDxh IGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpkcGF0aUByZWRoYXQu Y29tIj4mbHQ7ZHBhdGlAcmVkaGF0LmNvbSZndDs8L2E+ClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1i ZXIgNiwgMjAxMyAxMjowNzozNCBQTQpTdWJqZWN0OiBJTVA6IFJlZ2FyZGluZyBhbiBpc3N1ZSB3 aGlsZSB0cmFuc2xhdGluZyB0aGUgZXJyb3IgbWVzc2FnZXMgZm9yCmdsdXN0ZXIgdXNpbmcgRXJy b3JUcmFuc2xhdG9yIGNsYXNzCgpIaSwKCkluIHRoZSBjYXNlIG9mIEdsdXN0ZXIsIGFzIHRoZXJl IGFyZSBubyBvbmUgdG8gb25lIG1hcHBpbmdzIGF2YWlsYWJsZQpmb3IgYWxsIHRoZSBlcnJvciBt ZXNzYWdlcyBmcm9tIEdsdXN0ZXIsIHdlIHNldCB0aGUgZXJyb3IgaW4gdGhlClZkY0ZhdWx0IG9i amVjdCBhcyBOVUxMLgpXZSBhbHNvIHBvcHVsYXRlIHRoZSBhY3R1YWwgZXJyb3IgZnJvbSB0aGUg R2x1c3RlciBhcyBlcnJvciBtZXNzYWdlIGluCnRoZSBmYXVsdCBvYmplY3QuCgovZ2V0UmV0dXJu VmFsdWUoKS5nZXRFeGVjdXRlRmFpbGVkTWVzc2FnZXMoKS5hZGQoZXJyb3IpOy8vCi8vZ2V0UmV0 dXJuVmFsdWUoKS5nZXRGYXVsdCgpLnNldE1lc3NhZ2UoZXJyb3IpOy8vCi8vZ2V0UmV0dXJuVmFs dWUoKS5nZXRGYXVsdCgpLnNldEVycm9yKG51bGwpOy8KCkJlY2F1c2Ugb2YgYWJvdmUgc2V0dGlu Z3MgYW5kIHRoZSBiZWxvdyBjb2RlIHNuaXBwZXQgaW4gL0Zyb250ZW5kLmphdmEvCmNsYXNzIHRo ZSBlcnJvciBtZXNzYWdlIGFzIGlzIGdldHMgZGlzcGxheWVkIG9uIHRoZSBlcnJvciBkaWFsb2cg LQovCi8vcHVibGljIFN0cmluZyB0cmFuc2xhdGVWZGNGYXVsdChmaW5hbCBWZGNGYXVsdCBmYXVs dCkgey8vCi8vICAgICAgICByZXR1cm4KZ2V0VmRzbUVycm9yc1RyYW5zbGF0b3IoKS5UcmFuc2xh dGVFcnJvclRleHRTaW5nbGUoZmF1bHQuZ2V0RXJyb3IoKSA9PQpudWxsLy8KLy8gICAgICAgICAg ICAgICAgPyBmYXVsdC5nZXRNZXNzYWdlKCkgOiBmYXVsdC5nZXRFcnJvcigpLnRvU3RyaW5nKCkp Oy8vCi8vfS8vCi8KV2VsbCBhbmQgZ29vZCB0aWxsIG5vdyAhIQoKQnV0IHdoaWxlIHRyYW5zbGF0 aW9uIG9mIHRoZSBlcnJvciBtZXNzYWdlcywgYWxsIHRoZSBvY2N1cnJlbmNlcyBvZiAiLiIKZ2V0 IHJlcGxhY2VkIHdpdGggIl8iLgpUaGlzIGNhdXNlcyBhbiBpc3N1ZSBmb3IgdGhlIGdsdXN0ZXIg ZXJyb3JzLiBJZiB0aGUgZXJyb3IgbWVzc2FnZSBzZW50CmZyb20gZ2x1c3RlciBoYXMgIi4icyAo c2F5IElQIEFkZHJlc3Mgb2YgYSBob3N0IG9yIEZRRE4gZm9yIGEgaG9zdCksCnRoYXQgYWxzbyBn ZXRzIHJlcGxhY2VkIHdpdGggIl8iIGFuZCB0aGUgZXJyb3IgbWVzc2FnZSBkb2VzIG5vdCBsb29r CmNvcnJlY3QuCjwvcHJlPgogICAgICAgICAgPC9ibG9ja3F1b3RlPgogICAgICAgICAgPHByZSB3 cmFwPSIiPlRoaXMgbWVjaGFuaXNtIG9mIHJlcGxhY2luZyBbMV0gaGFzIGJlZW4gaW50cm9kdWNl ZCB0byBhbGxvdyBwcm9wZXIKbWVzc2FnZSB0cmFuc2xhdGlvbiB3aGVuIHJldHJpZXZpbmcgYSBt ZXNzYWdlIGtleSB0aGF0IGNvbnRhaW5zIGRvdHMuCkUuZy4gQXBwRXJyb3JzLnByb3BlcnRpZXMg LSZndDsgVkFMSURBVElPTi5ST0xFUy5OQU1FLk1BWCBpcyB0cmFuc2xhdGVkCnRvIFZBTElEQVRJ T05fUk9MRVNfTkFNRV9NQVggaW4gQXBwRXJyb3JzLmphdmEgaW50ZXJmYWNlIChhcyBpbnRlcmZh Y2UKc2lnbmF0dXJlcyBjYW5ub3QgY29udGFpbiBkb3RzLiBOb3RlIHRoYXQgdGhpcyBwcm9jZXNz IHNob3VsZG4ndAphZGRyZXNzIHRoZSBtZXNzYWdlOyBpLmUuIG9ubHkgdGhlIGtleSBpcyBleGFt aW5lZCBmb3IgZG90cy4KCkFzIHlvdSd2ZSBtZW50aW9uZWQgVmRzbUVycm9yc1RyYW5zbGF0b3Ig SSBndWVzcyB0aGVyZSdzIGFuIGlzc3VlCm9ubHkgd2hlbiB0cmFuc2xhdGluZyBWZHNtRXJyb3Jz IG1lc3NhZ2VzLgpDYW4geW91IHBsZWFzZSBzZW5kIGFuIGV4YW1wbGUgb2YgYSBtZXNzYWdlIHVz YWdlPwo8L3ByZT4KICAgICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgICAgPHByZSB3cmFwPSIiPk9u ZSBleGFtcGxlIG9mIHRoZSBlcnJvciBtZXNzYWdlIHdoaWNoIGlzIHNob3duIG9uIHRoZSBkaWFs b2cgYWZ0ZXIKdHJhbnNsYXRpb24gaXMgYXMgYmVsb3cgLQoKLyJFcnJvciB3aGlsZSBleGVjdXRp biBhY3Rpb24gQ3JlYXRlIEdsdXN0ZXIgVm9sdW1lOiBWb2x1bWUgY3JlYXRlCmZhaWxlZCBlcnJv cjogU3RhZ2luZyBmYWlsZWQgb24gLy8qMTBfNzBfNDNfMTIyXyovL0Vycm9yOiAvZXhwb3J0L3Zv bDEtYQppcyBhbHJlYWR5IHBhcnQgb2YgYSB2b2x1bWUiLwo8L3ByZT4KICAgICAgPC9ibG9ja3F1 b3RlPgogICAgICA8cHJlIHdyYXA9IiI+CldoYXQgYXJlIHRoZSBrZXlzIHRoYXQgYmVlbiBzZW50 IGZyb20gdGhlIGVuZ2luZSAoaS5lLiB0aGUgbWVzc2FnZSBiZWZvcmUgdHJhbnNsYXRpb24pPzwv cHJlPgogICAgPC9ibG9ja3F1b3RlPgogICAgV2Ugc2V0IG1lc3NhZ2UgY29kZSBhcyBOVUxMIGFu ZCBlcnJvciBtZXNzYWdlIGlzIHNldCBhcyBpcyB3aGF0ZXZlcgogICAgaXMgcmVjZWl2ZWQgZnJv bSBWRFNNLiBNZXNzYWdlIGNvbnRhaW5zIGRvdHMgKCIuIikgYXMgcGFydCBvZiBpdC48YnI+CiAg ICBDb2RlIHNuaXBwZXQgaXMgc2hvd24gYmVsb3cgLTxicj4KICAgIDxwcmUgd3JhcD0iIj48Zm9u dCBjb2xvcj0iIzMzMzNmZiI+PGk+Z2V0UmV0dXJuVmFsdWUoKS5nZXRFeGVjdXRlRmFpbGVkTWVz c2FnZXMoKS5hZGQoZXJyb3IpOwpnZXRSZXR1cm5WYWx1ZSgpLmdldEZhdWx0KCkuc2V0TWVzc2Fn ZShlcnJvcik7CmdldFJldHVyblZhbHVlKCkuZ2V0RmF1bHQoKS5zZXRFcnJvcig8Zm9udCBjb2xv cj0iI2ZmMDAwMCI+bnVsbDwvZm9udD4pOzwvaT48L2ZvbnQ+PC9wcmU+CiAgICA8YnI+CiAgICA8 YmxvY2txdW90ZQogICAgICBjaXRlPSJtaWQ6MTUxNDU2MjkxNi4yNjk1ODMwMC4xMzgzNzUzNTYx OTk4LkphdmFNYWlsLnJvb3RAcmVkaGF0LmNvbSIKICAgICAgdHlwZT0iY2l0ZSI+CiAgICAgIDxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPgogICAgICAgIDxwcmUgd3JhcD0iIj4KSWYgeW91IHNlZSB0 aGUgaGlnaGxpZ2h0ZWQgcG9ydGlvbiBub3Qgb25seSB0aGUgZG90cyBpbiBJUCBhZGRyZXNzIGJ1 dAphbHNvIHRoZSBmdWxsIHN0b3AgaXMgY2hhbmdlZCB0byAiXyIuCjwvcHJlPgogICAgICAgIDxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPgogICAgICAgICAgPHByZSB3cmFwPSIiPihhbmQgbWF5YmUg dHJ5IHRoZSBzYW1lIG1lc3NhZ2UgdXNpbmcgQXBwRXJyb3JzIGluc3RlYWQpCjwvcHJlPgogICAg ICAgIDwvYmxvY2txdW90ZT4KICAgICAgICA8cHJlIHdyYXA9IiI+VGhlcmUgYXJlIG5vIG9uZSB0 byBvbmUgbWFwcGluZyBvZiB0aGVzZSBtZXNzYWdlcyBpbiBBcHBFcnJvcnMgYXMgdGhleQphcmlz ZSByYW5kb21seSwgc28gaW4gc3VjaCBjYXNlcyB3ZSB0aHJvdyB0aGUgVkRTTSBlcnJvciBtZXNz YWdlIGFzIGlzCm9uIHRoZSBkaWFsb2cuCjwvcHJlPgogICAgICAgIDxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPgogICAgICAgICAgPHByZSB3cmFwPSIiPgpbMV0gRXJyb3JUcmFuc2xhdG9yIC0mZ3Q7 IHRyYW5zbGF0ZUVycm9yVGV4dFNpbmdsZSgpCgo8L3ByZT4KICAgICAgICAgIDxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPgogICAgICAgICAgICA8cHJlIHdyYXA9IiI+UmVxdWVzdCB5b3VyIHN1Z2dl c3Rpb24gZm9yIGhhbmRsaW5nIHN1Y2ggYSBjYXNlLgoKKlBTOiAqT25lIHRoaW5nIEkgY2FuIHRo aW5rIG9mIGlzLCBpbnRyb2R1Y2luZyBhIGZsYWcgY2FsbGVkCi9pc0V4dGVybmFsRXJyb3IvIGlu IC9WZGNGYXVsdC8gY2xhc3MgdG8gaWRlbnRpZnkgaWYgdGhlIHNvdXJjZSBvZiB0aGUKZmF1bHQg aXMgZXh0ZXJuYWwuIEZyb20gR2x1c3RlciB3ZSB3b3VsZCBzZXQgdGhlIGZsYWcgYXMgL3RydWUv LCBhbmQKd2hpbGUgcmVwbGFjZW1lbnQgb2YgIi4iIHdpdGggIl8iLCBpZiB0aGUgZmxhZyBpcyBz ZXQgaXQgd2lsbCBub3QgZG8gdGhlCnJlcGxhY2VtZW50cy4KClJlZ2FyZHMsClNodWJoZW5kdQoK PC9wcmU+CiAgICAgICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgICAgPC9ibG9ja3F1b3RlPgogICAg ICAgIDxwcmUgd3JhcD0iIj4KCjwvcHJlPgogICAgICA8L2Jsb2NrcXVvdGU+CiAgICA8L2Jsb2Nr cXVvdGU+CiAgICA8YnI+CiAgPC9ib2R5Pgo8L2h0bWw+CgotLS0tLS0tLS0tLS0tLTA0MDMwMjAx MDgwMTA1MDIwMjAzMDMwOC0tCg== --===============8621158009880736323==-- From shtripat at redhat.com Sat Nov 9 04:07:50 2013 Content-Type: multipart/mixed; boundary="===============3063500891628069444==" MIME-Version: 1.0 From: Shubhendu Tripathi To: devel at ovirt.org Subject: Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class Date: Sat, 09 Nov 2013 14:37:44 +0530 Message-ID: <527DFB60.6020709@redhat.com> In-Reply-To: 1082228530.20856483.1383747009016.JavaMail.root@redhat.com --===============3063500891628069444== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 11/06/2013 07:40 PM, Einav Cohen wrote: >> ----- Original Message ----- >> From: "Alexander Wels" >> 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 s= tart >> 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 "$v= m-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 eventua= lly be displayed. > but, as I mentioned, if you will get message "$vm-name vm1" along with me= ssage "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 mes= sage > 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 i= t a while ago). There is an upstream patch according to Einav's suggestion above. http://gerrit.ovirt.org/#/c/21083/ > >> 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() =3D= =3D >>> 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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > --===============3063500891628069444==-- From ecohen at redhat.com Mon Nov 11 10:18:12 2013 Content-Type: multipart/mixed; boundary="===============3108505061126249750==" MIME-Version: 1.0 From: Einav Cohen To: devel at ovirt.org Subject: Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class Date: Mon, 11 Nov 2013 10:18:12 -0500 Message-ID: <1134168809.817930.1384183092189.JavaMail.root@redhat.com> In-Reply-To: 527DFB60.6020709@redhat.com --===============3108505061126249750== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > ----- Original Message ----- > From: "Shubhendu Tripathi" > Sent: Saturday, November 9, 2013 4:07:44 AM > = > On 11/06/2013 07:40 PM, Einav Cohen wrote: > >> ----- Original Message ----- > >> From: "Alexander Wels" > >> Sent: Wednesday, November 6, 2013 8:28:13 AM > >> > >> Looking at the code, if you start the error message with a $ it will n= ot > >> 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 be= st = 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.jav= a/ > >>> class the error message as is gets displayed on the error dialog - > >>> / > >>> //public String translateVdcFault(final VdcFault fault) {// > >>> // return > >>> getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() = =3D=3D > >>> 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(a)ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > > = > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > = > = >=20 --===============3108505061126249750==-- From shtripat at redhat.com Thu Nov 21 05:36:06 2013 Content-Type: multipart/mixed; boundary="===============8165909289085062199==" MIME-Version: 1.0 From: Shubhendu Tripathi To: devel at ovirt.org Subject: Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class Date: Thu, 21 Nov 2013 16:05:41 +0530 Message-ID: <528DE1FD.4000007@redhat.com> In-Reply-To: 1134168809.817930.1384183092189.JavaMail.root@redhat.com --===============8165909289085062199== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 11/11/2013 08:48 PM, Einav Cohen wrote: >> ----- Original Message ----- >> From: "Shubhendu Tripathi" >> Sent: Saturday, November 9, 2013 4:07:44 AM >> >> On 11/06/2013 07:40 PM, Einav Cohen wrote: >>>> ----- Original Message ----- >>>> From: "Alexander Wels" >>>> Sent: Wednesday, November 6, 2013 8:28:13 AM >>>> >>>> Looking at the code, if you start the error message with a $ it will n= ot >>>> 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)? Daniel, any comments on the patch ? http://gerrit.ovirt.org/#/c/21083/ > >>>> 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.jav= a/ >>>>> class the error message as is gets displayed on the error dialog - >>>>> / >>>>> //public String translateVdcFault(final VdcFault fault) {// >>>>> // return >>>>> getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() = =3D=3D >>>>> 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(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> >> > --===============8165909289085062199==--