Re: [Engine-devel] oVirt UI technology stack upgrade complete
- Original Message - From: Vojtech Szocs vsz...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, August 19, 2013 3:46:56 PM Subject: Re: [Engine-devel] oVirt UI technology stack upgrade complete - Original Message - From: Allon Mureinik amure...@redhat.com To: Vojtech Szocs vsz...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Thursday, August 15, 2013 12:52:55 PM Subject: Re: [Engine-devel] oVirt UI technology stack upgrade complete Thanks for the detailed explanation on the field initialization issues, Vojtech. Looking at the common and compat packages, there a dozens of such initializers. Some are probably redundant anyway and can safely be ignored, but some (most?) have a purpose. My incline is always to prevent such issues from happening, and not rely on developers having to remember to move their initializers. Here's my take on the issue (patchset available for review at [1]): - Move all member initializers to constructors - Add a checkstyle check to ensure that new members aren't initialized inline Nice work, Allon. I agree with your point not to rely solely on developers (having to remember GWT-specific limitations) but solving this issue globally in common compat modules. I went over patches at [1] that aren't fully-acked yet, they looked good to me. Patchset was merged. A bug thank you to all the reviewers! Reviews are welcome, thanks! -Allon [1] http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:no-member-init,n,z - Original Message - From: Vojtech Szocs vsz...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Wednesday, July 31, 2013 4:17:30 PM Subject: [Engine-devel] oVirt UI technology stack upgrade complete Hello everyone, last week, we merged a patch that upgrades oVirt UI technology stack to use the latest version of Google Web Toolkit SDK and related modules [1]. This patch includes all essential upgrade changes as described in [2]. After merging the above mentioned patch, we faced some issues related to GWT RPC serialization, involving classes shared between frontend and backend. Please read on to learn more about these issues and ways to fix them. -- (A) NullPointerException at server-side (GWT RPC servlet) when serializing backend business entity into RPC response payload Symptoms * exception in server.log - Exception while dispatching incoming RPC call: java.lang.NullPointerException * error dialog in web UI with status code 500 (internal server error) Root cause * fields such as private X field = Y; of the given entity are not included in GWT RPC serialization policy * this happens when entity constructor isn't referenced in UI code - GWT compiler marks the constructor and instance initializer as dead code * since instance initializer takes care of adding such fields to given type (entity) in generated JavaScript, such fields won't be added at all Workaround * for each field such as private X field = Y; 1, change field declaration to private X field; 2, add field = Y; statement to constructor Consequence * even though constructor and instance initializer are marked as dead code, fields such as private X field; are still added to given type (entity) in generated JavaScript * this is due to how generated JavaScript works, i.e. fields without initialization statement such as private X field; are always added, whereas fields with initialization statement such as private X field = Y; are added via instance initializer (which might be removed if it's marked as dead code) References * patch [http://gerrit.ovirt.org/#/c/17352/] for RepoImage entity -- (B) Instance field(s) with null values at server-side after deserializing RPC request payload Symptoms * object passed from client contains field(s) with null values, despite client initializing fields before making RPC call Root cause * client uses RPC method signature that works with type A, i.e. VdcActionParametersBase * type A meets GWT RPC serialization rules, as defined in [3] section Serializable User-defined Classes * client uses type B (extends A) when calling given RPC method at runtime, i.e. MyCustomParameters * type B does NOT meet GWT RPC serialization rules, i.e. missing no-arg constructor * back at server-side, GWT RPC servlet fails to deserialize type B properly Workaround * ensure all types participating in GWT RPC communication meet GWT RPC serialization rules 1, assignable to IsSerializable or Serializable interface 2, all non-final non-transient instance fields meet GWT RPC serialization rules 3, contains
[Engine-devel] Rebuild ovirt 3.2.1 success, but lost i18n support
Hi all, I just rebuild ovirt-engine 3.2.1 according to http://www.ovirt.org/Building_oVirt_engine , it work fine, but I could not choose the language, it always display U.S. English UI. Could you give me a hand, how can I enable GWT's i18n support, or something is wrong in my building ENV? Thanks in advance. -- Bests, An Yang ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Rebuild ovirt 3.2.1 success, but lost i18n support
Hi all, I just rebuild ovirt-engine 3.2.1 aaccording to http://www.ovirt.org/Building_oVirt_engine , it work fine, but I could not choose the language, it always display U.S. English UI. Could you give me a hand, how can I enable GWT's i18n support, or something is wrong in my building ENV? Thanks in advance. An Yang signature.asc Description: This is a digitally signed message part ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Gluster Volume asynchronous tasks
On 08/20/2013 04:00 AM, Itamar Heim wrote: On 08/12/2013 06:09 AM, Sahina Bose wrote: On 08/12/2013 03:28 PM, Yair Zaslavsky wrote: - Original Message - From: Sahina Bose sab...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org, a...@ovirt.org Sent: Monday, August 12, 2013 11:51:15 AM Subject: Re: [Engine-devel] Gluster Volume asynchronous tasks On 08/12/2013 01:21 PM, Eli Mesika wrote: - Original Message - From: Sahina Bose sab...@redhat.com To: engine-devel engine-devel@ovirt.org, a...@ovirt.org, Michael Pasternak mpast...@redhat.com Sent: Monday, August 12, 2013 8:41:55 AM Subject: [Engine-devel] Gluster Volume asynchronous tasks Hi all, We are working on a feature to add support to start and monitor gluster volume asynchronous tasks (like rebalancing a gluster volume, removing brick from volume ) from the oVirt engine. The operations can be started from the Volumes tab or the Bricks sub-tab using the Rebalance, Remove options. These are long running operations which can be monitored using a task id returned from Gluster. We are planning to add the monitoring in the existing Task sub tab The feature description and User flows are at http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management The detailed design (including REST API design) is at http://www.ovirt.org/Features/Detailed_Gluster_Volume_Asynchronous_Tasks_Management. I would really appreciate if you could review and provide your valuable feedback. I Sahina Why not using 6the External Tasks feature introduced for 3.3 for those Gluster tasks ??? http://www.ovirt.org/Features/Design/DetailedExternalTasks Hi Eli, We still want to be able to start and stop these operations from the engine. So, when a user wants to say, rebalance a volume, they would go select the volume and click on Rebalance Start. This would then call the BLL command to start rebalance which will invoke the corresponding vdsm verb to start the rebalance on the volume. This is the same as existing flow for other commands. The only difference is the vdsm verb will return the task id from gluster, for the rebalance operation that was started. And we will monitor the progress of the task using the gluster task id (by calling a gluster command) I'm not sure how ExternalTasks would fit in here? I was thinking of using ExternalTask support for adding Job/Steps to engine when the operation is started outside of engine, that is, from Gluster CLI. Please correct me if I'm missing something. Does this mean that from Gluster CLI you will not try and invoke the rebalance command ? (I mean, I should either use Gluster CLI or Engine's REST API?) Rebalance volume command could be invoked in any of the following ways: 1. From the console UI (clicking on Rebalance as shown in http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management#Rebalance_Volume) 2. Using REST API 3. Outside of engine, from Gluster CLI - In such cases, the engine should detect that a user has triggered rebalance operation outside the engine, and allow the user to monitor progress of this from the engine. This is where, we need support to add a Job for an operation that was started externally, so that it can be seen in the Tasks tab. and still, it should be considered an internal task, since the engine is managing it / detected it. Itamar, yes, you are right. This would need to be treated as an internal task as the engine needs to be able to stop it and also monitor it. We would probably need a similar mechanism as external task injection, to add a Job for the task started from gluster CLI. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
