Re: [Engine-devel] Proposing Liron Aravot as an engine-core maintainer
- Original Message - From: Tal Nisan tni...@redhat.com To: Itamar Heim ih...@redhat.com, Livnat Peer lp...@redhat.com, Omer Frenkel ofren...@redhat.com, Doron Fediuck dfedi...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Maor Lipchuk mlipc...@redhat.com, Roy Golan rgo...@redhat.com, Eli Mesika emes...@redhat.com, Mike Kolesnik mkole...@redhat.com, Moti Asayag masa...@redhat.com, Shahar Havivi shav...@redhat.com, ov...@redhat.com, Allon Mureinik amure...@redhat.com Cc: engine-devel engine-devel@ovirt.org, in...@ovirt.org Sent: Sunday, January 26, 2014 2:47:30 PM Subject: Proposing Liron Aravot as an engine-core maintainer Hi core maintainers, I would like to propose Liron Aravot as an engine-core maintainer. Liron joined the oVirt project on June 2012, and has since contributed over 170 patches to master (not counting backports to various stable branches). He has been instrumental in implementing oVirt's Backup API for external providers, and has a been a driving force in improving flows regarding SPM election and master domain reconstruction, handling OVF backups and various concurrency issues both as a coder and a reviewer. Your response would be appreciated. I've worked with Liron since the very first day he joined oVirt and have been impressed by his analytic capabilities and by his keen sense for detail on more than one occasion. +1, full-heartedly. Thanks, Tal. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] IMPORTANT: FindBugs threshold update
- Original Message - From: Moti Asayag masa...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Thursday, January 2, 2014 11:46:29 AM Subject: Re: [Engine-devel] IMPORTANT: FindBugs threshold update - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Moti Asayag masa...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, Eyal Edri ee...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Thursday, January 2, 2014 11:12:17 AM Subject: Re: [Engine-devel] IMPORTANT: FindBugs threshold update - Original Message - From: Moti Asayag masa...@redhat.com To: Oved Ourfalli ov...@redhat.com, Eyal Edri ee...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Thursday, January 2, 2014 12:08:43 AM Subject: Re: [Engine-devel] IMPORTANT: FindBugs threshold update - Original Message - From: Oved Ourfalli ov...@redhat.com To: engine-devel engine-devel@ovirt.org, Allon Mureinik amure...@redhat.com, Alissa Bonas abo...@redhat.com Sent: Wednesday, January 1, 2014 4:25:50 PM Subject: [Engine-devel] IMPORTANT: FindBugs threshold update Hi all, Up until now the jenkins jobs on the gerrit patches included a findbugs job, that failed only in case of a warning of level NORMAL or higher. Now we update this threshold to fail on any findbugs warning, including LOW ones. Moti - 1. Aren't use running a local jenkins instance on one of your hosts? Maybe Eyal can publish the findbugs job? Well...that server is on maintenance for quite a while... 2. What about running the findbugs UI? I find it kinda handy... The findbugs UI expects the xml created by findbugs with all of the violations. The question is how those violation are created ? where are the rules by which findbugs verifies the code (can be findbugs jar or jenkins findbugs plugin or other...). Currently by running 'mvn findbugs:findbugs' i don't get a a single xml aggregating all of the violations and the produced ones contain a lot of warnings. So I'd like to know how can i be able to run this test locally ? You're missing the profile with the project's exclusions. What you'd want to do is probably this: mvn findbugs:check -Pfindbugs-general This way you won't have to go over any report, you will just fail the build if you introduce a regression. Could you provide instructions of running findbugs locally and how to evaluate the result the same as done by the jenkins job ? Please make sure to rebase your current patches and check that the findbugs job finish successfully. It will probably fail without a rebase, as the last patches clearing the warnings were merged a few hours ago. Kodus to everyone involved in clearing all the LOW level warnings... mostly Allon and Alissa, but others helped as well! :-) Well done! Great news - good work guys! Cheers, Oved ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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
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 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 no-arg constructor (in order to create instance during deserialization) References * patch [http://gerrit.ovirt.org/#/c/17368/] for Gluster Parameter classes -- Regards, Vojtech [1] http://gerrit.ovirt.org/#/c/16739/ [2] http://www.ovirt.org/Features/GWT_Platform_Upgrade [3] http://www.gwtproject.org/doc/latest/DevGuideServerCommunication.html#DevGuideSerializableTypes ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] LockManager maybe not be really taking locks in your flows...
- Original Message - From: Roy Golan rgo...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Sunday, August 11, 2013 5:16:47 PM Subject: Re: [Engine-devel] LockManager maybe not be really taking locks in your flows... On Sun 11 Aug 2013 05:14:04 PM IDT, Roy Golan wrote: On Sun 11 Aug 2013 05:03:05 PM IDT, Yair Zaslavsky wrote: Hi all, Thanks to Alon Bar Lev's efforts for preventing to concurrent host installation for the same host entity + Roy Golan's check of the code, we saw that for commands that override getExclusiveLocks() or getSharedLocks() the locking mechanism does not work (lock is not being acquired) if there is no annotation of @LockIdNameAttribute on the class. A bug was filed for removing this annotation (leftover from some historical code ) , but until it is fixed - bare in mind you need to add this annotation in current commands you are working on in order to utilize the mechanism. See RemoveVmCommand (has the annotation) vs AddDiskCommand (which doesn't have the annotation) Cheers, Yair ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel just to make it clear, the storage commands are calling explicitly aquireLockInternal in the canDoAction. since there is no contract (no interface) we are open to mistakes and misuse. this should be rectified. more info from the bug: see the list of commands that overrrides getExcelusiveLocks but *don't* have the @LockIdNameAttribute annotation: bll/src/main/java/org/ovirt/engine/core/bll/AddDiskCommand.java Manually calls acquireLockInternal() - disgusting, but works (on my todo list for some future version, don't worry). bll/src/main/java/org/ovirt/engine/core/bll/MoveOrCopyDiskCommand.java Same. bll/src/main/java/org/ovirt/engine/core/bll/AddVdsCommand.java bll/src/main/java/org/ovirt/engine/core/bll/UpdateVmTemplateCommand.java bll/src/main/java/org/ovirt/engine/core/bll/ExportRepoImageCommand.java ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] LockManager maybe not be really taking locks in your flows...
- Original Message - From: Allon Mureinik amure...@redhat.com To: Roy Golan rgo...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, August 12, 2013 9:59:17 AM Subject: Re: [Engine-devel] LockManager maybe not be really taking locks in your flows... - Original Message - From: Roy Golan rgo...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Sunday, August 11, 2013 5:16:47 PM Subject: Re: [Engine-devel] LockManager maybe not be really taking locks in your flows... On Sun 11 Aug 2013 05:14:04 PM IDT, Roy Golan wrote: On Sun 11 Aug 2013 05:03:05 PM IDT, Yair Zaslavsky wrote: Hi all, Thanks to Alon Bar Lev's efforts for preventing to concurrent host installation for the same host entity + Roy Golan's check of the code, we saw that for commands that override getExclusiveLocks() or getSharedLocks() the locking mechanism does not work (lock is not being acquired) if there is no annotation of @LockIdNameAttribute on the class. A bug was filed for removing this annotation (leftover from some historical code ) , but until it is fixed - bare in mind you need to add this annotation in current commands you are working on in order to utilize the mechanism. See RemoveVmCommand (has the annotation) vs AddDiskCommand (which doesn't have the annotation) Cheers, Yair ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel just to make it clear, the storage commands are calling explicitly aquireLockInternal in the canDoAction. since there is no contract (no interface) we are open to mistakes and misuse. this should be rectified. more info from the bug: see the list of commands that overrrides getExcelusiveLocks but *don't* have the @LockIdNameAttribute annotation: bll/src/main/java/org/ovirt/engine/core/bll/AddDiskCommand.java Manually calls acquireLockInternal() - disgusting, but works (on my todo list for some future version, don't worry). bll/src/main/java/org/ovirt/engine/core/bll/MoveOrCopyDiskCommand.java Same. bll/src/main/java/org/ovirt/engine/core/bll/AddVdsCommand.java bll/src/main/java/org/ovirt/engine/core/bll/UpdateVmTemplateCommand.java bll/src/main/java/org/ovirt/engine/core/bll/ExportRepoImageCommand.java Fixed: http://gerrit.ovirt.org/#/c/17946/ ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Linking to bugs from oVirt wiki
Hi guys,
Since a lot of us will be busy opening bugs as part of the oVirt Test Day, I
cooeked up a quick template to help adding Bugzilla links.
You can just use {BZ|number} in your wiki markup, and you'll get a
user-friendly link to Bugzilla with the given number (e.g., {BZ|123} will
create a link to http://bugzilla.redhat.com/123).
Enjoy,
Allon
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Linking to bugs from oVirt wiki
- Original Message -
From: Allon Mureinik amure...@redhat.com
To: engine-devel engine-devel@ovirt.org, vdsm-de...@lists.fedorahosted.org
Sent: Wednesday, July 24, 2013 2:54:44 PM
Subject: Linking to bugs from oVirt wiki
Hi guys,
Since a lot of us will be busy opening bugs as part of the oVirt Test Day, I
cooeked up a quick template to help adding Bugzilla links.
You can just use {BZ|number} in your wiki markup, and you'll get a
{{BZ|number}} of course.
Thanks Alissa for pointing this out. ;-)
user-friendly link to Bugzilla with the given number (e.g., {BZ|123} will
create a link to http://bugzilla.redhat.com/123).
Enjoy,
Allon
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Kudos to Allon Mureinik for his 1, 000 patch merged
Thanks! Although I would have expected the milestone to be at 1024 :-) - Original Message - From: Itamar Heim ih...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, July 4, 2013 9:59:40 PM Subject: [Engine-devel] Kudos to Allon Mureinik for his 1,000 patch merged While 1,000 is an arbitrary number, kudos to Allon for his 1,000 patch to ovirt-engine repo being merged[1]! (yes, a lot of these are cleanup patches, but these matter too). Thanks, Itamar [1] you can use 'git shortlog -sn' to get the full list. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Guid improvements
- Original Message - From: Liran Zelkha liran.zel...@gmail.com To: Allon Mureinik amure...@redhat.com Cc: Yair Zaslavsky yzasl...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Monday, July 1, 2013 10:36:06 AM Subject: Re: [Engine-devel] Guid improvements Awesome!!! On Mon, Jul 1, 2013 at 10:29 AM, Allon Mureinik amure...@redhat.com wrote: - Original Message - From: Liran Zelkha liran.zel...@gmail.com To: Yair Zaslavsky yzasl...@redhat.com Cc: Allon Mureinik amure...@redhat.com , engine-devel engine-devel@ovirt.org Sent: Sunday, June 30, 2013 11:37:26 AM Subject: Re: [Engine-devel] Guid improvements Great news. Allon - please note that GUID is being recreated from String by both DB calls and by data received from VDSM. It is VERY useful to cache Guid String--Guid, and not just Empty GUID. I generally agree about the high cost of sting-uuid operations, but I'm not sure caching is the way to go, at least not everywhere. At least for the database, there is a much easier solution - stop using strings to represent uuids. Here's an example of how it can be done: http://gerrit.ovirt.org/#/c/16281/ This patchset was merged [1]. Along with a couple of uber-neat improvements by Juan [2][3], I think we should see a real boost in performance. [1] http://gerrit.ovirt.org/#/q/status:merged+project:ovirt-engine+branch:master+topic:guid-database-improvements,n,z [2] http://gerrit.ovirt.org/#/c/16421/ [3] http://gerrit.ovirt.org/#/c/16467/ However, as the Guid class runs in GWT as well, you can't use Infinispan and you're limited in the HashMap implementations you can use. Personally, I don't think it's a memory leak, as GUID number in the system are finite and not too large. What do you think? Want to add it to your patch? On Jun 30, 2013, at 11:13 AM, Yair Zaslavsky wrote: Well done, should have been done ages ago :) Now, for the painful rebase of async_task_mgr changes :) - Original Message - From: Allon Mureinik amure...@redhat.com To: engine-devel engine-devel@ovirt.org , Barak Azulay bazu...@redhat.com Cc: Yair Zaslavsky yzasl...@redhat.com , Michael Pasternak mpast...@redhat.com , Tal Nisan tni...@redhat.com , Ayal Baron aba...@redhat.com Sent: Sunday, June 30, 2013 11:11:30 AM Subject: Guid improvements Hi all, I just merged a couple of improvements to the [N]Guid class [1] to improve it's performance both CPU-wise and memory-wise, based on a set of benchmarks presented by Liran. What this patchset achieves: 1. Clean up the code, so it's easier to understand and use 2. Eliminate the inflation in the memory foot print caused by the getValue() method 3. Eliminate all the heavy calls to UUID.fromString when creating a new/empty Guid instance as a default value 4. Note that the cleanups proposed in (1) will have minor performance benefits (e.g., eliminating useless conditional statements), but I doubt this would be anything to write home about. From a developer's perspective, here's what changed: 1. No more NGuid, just Guid. Both static methods to create a Guid from String still exist, and are named createGuidFromString and createGuidFromStringDefaultEmpty. 2. [N]Guid.getValue() was removed, it's no longer needed after (1) was implemented 3. The Guid() constructor was made private, as it forced a redundant call to UUID.fromString(String). If you need an empty Guid instance, just use Guid.Empty 4. The Guid.EMPTY_GUID_VALUE string constant was removed, as it was used for redundant calls to UUID.fromString. If you really, REALLY, need it, just call Guid.Empty.getValue() for a UUID or Guid.Empty.toString() for a String. 5. All sorts of ways to transform Strings to Guids were removed. If you have a literal you trust, just use new Guid(String). If you suspect it may be null, use Guid.createGuidFromString[DefaultEmpty] 6. NewGuid is now called newGuid. We're in Java, not C# :-) Many thanks to everyone who reviewed this patchset. You guys rock! Regards, Allon [1] http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:guid-cleanup,n,z ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Guid improvements
Hi all, I just merged a couple of improvements to the [N]Guid class [1] to improve it's performance both CPU-wise and memory-wise, based on a set of benchmarks presented by Liran. What this patchset achieves: 1. Clean up the code, so it's easier to understand and use 2. Eliminate the inflation in the memory foot print caused by the getValue() method 3. Eliminate all the heavy calls to UUID.fromString when creating a new/empty Guid instance as a default value 4. Note that the cleanups proposed in (1) will have minor performance benefits (e.g., eliminating useless conditional statements), but I doubt this would be anything to write home about. From a developer's perspective, here's what changed: 1. No more NGuid, just Guid. Both static methods to create a Guid from String still exist, and are named createGuidFromString and createGuidFromStringDefaultEmpty. 2. [N]Guid.getValue() was removed, it's no longer needed after (1) was implemented 3. The Guid() constructor was made private, as it forced a redundant call to UUID.fromString(String). If you need an empty Guid instance, just use Guid.Empty 4. The Guid.EMPTY_GUID_VALUE string constant was removed, as it was used for redundant calls to UUID.fromString. If you really, REALLY, need it, just call Guid.Empty.getValue() for a UUID or Guid.Empty.toString() for a String. 5. All sorts of ways to transform Strings to Guids were removed. If you have a literal you trust, just use new Guid(String). If you suspect it may be null, use Guid.createGuidFromString[DefaultEmpty] 6. NewGuid is now called newGuid. We're in Java, not C# :-) Many thanks to everyone who reviewed this patchset. You guys rock! Regards, Allon [1] http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:guid-cleanup,n,z ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] checkstyle and tools project
checkstyle runs as part of a compile phase in mvn. as long as you build your code before submitting it to gerrit you should be scott-free. - Original Message - From: Eyal Edri ee...@redhat.com To: Laszlo Hornyak lhorn...@redhat.com Cc: engine-devel engine-devel@ovirt.org, infra in...@ovirt.org Sent: Monday, June 24, 2013 5:28:44 PM Subject: Re: [Engine-devel] checkstyle and tools project Can we add a gerrit hook to run checkstyle on the code? rather than waiting it to be merged and fail on jenkins? - Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Monday, June 24, 2013 11:15:38 AM Subject: [Engine-devel] checkstyle and tools project Hi, Checkstyle is not executed on tools project. I have sent a patch to gerrit to fix this, could you guys review? http://gerrit.ovirt.org/15719 And there are some more cleanup patches for tools: http://gerrit.ovirt.org/15720 http://gerrit.ovirt.org/15721 http://gerrit.ovirt.org/15722 Thank you, Laszlo ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Disk BE very small refactoring
- Original Message - From: Vered Volansky ve...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, June 2, 2013 12:02:55 PM Subject: Re: [Engine-devel] Disk BE very small refactoring - Original Message - From: Eli Mesika emes...@redhat.com To: Vered Volansky ve...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, May 30, 2013 12:57:26 PM Subject: Re: [Engine-devel] Disk BE very small refactoring - Original Message - From: Omer Frenkel ofren...@redhat.com To: Vered Volansky ve...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, May 30, 2013 11:29:40 AM Subject: Re: [Engine-devel] Disk BE very small refactoring - Original Message - From: Vered Volansky ve...@redhat.com To: Maor Lipchuk mlipc...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Omer Frenkel ofren...@redhat.com, Mike Kolesnik mkole...@redhat.com, Allon Mureinik amure...@redhat.com, Daniel Erez de...@redhat.com Cc: engine-devel@ovirt.org Sent: Tuesday, May 28, 2013 8:40:38 PM Subject: Re: [Engine-devel] Disk BE very small refactoring I had a problem, didn't see all the replies till now. I'll add some more info as to why we want to do this like we do. It all started from adding the readOnly property to disks. It should have been handled like plugged is handled, yet plugged is a hack, and if we don't change that now, we'll only keep on adding unreasonable hacks. please explain why you think plugged is a hack? what is wrong with it? You have is_readonly and is_plugged in the device level , this is far from being a hack and managed in the correct place since both may apply to multiple device types (disk, nics ) There's no problem with device level, only I can't use VmDevice (which is where this naturally belongs) in UI since it will cause a major change we don't want right now. Not only that, VmDevice does hold this info, but not other relevant info used in UI and available in Disk, so using VmDevice on it's own is not only to extensive a change, but also by far will not end there. So from the start - Disk currently: - Sometimes represents a disk in a vm context and sometimes not. - Holds plugged property, which is only relevant when a disk is in a vm context, which already suggests this is not the natural place for it. - Also holds bootable and interface, which cause limitations of use, but are not so obviously related to the relationship between Disk and Vm as plugged. - Can be shared between several vm's, to some plugged and to some not plugged. - Will soon be optionally RO in one VM and RW in another, which is exactly the same as plugged, and therefore plugged issue should be fixed first. Every column in that shows a disk in the UI receives a Disk entity, and show its contents, while plugged/unplugged is ignored when not in a VM context. The way things are now, using a VmDevice in the where we need it to show plug status, we'll also have to use it in all other columns, which is irrelevant and just totally not related. So using VmDevice in UI is a no go. The UI is the main limitation forcing us to use something that extends Disk, and what I described below is the easiest thing to implement in the time restrictions we have without changing the entire system. I think this answers all the questions not already answered by others. Regarding Maor suggestion - might be a good idea, but not in this scope or time-frame. If there is any other/unanswered issue or objection to the design change please share. I appreciate your inputs, Vered sorry i didnt understand why the current disk object isnt good enough, you get a disk, some of its properties are valid only in some situations. i think its easier to use instead of couple of different objects representing the same entity in different situations. I totally agree with Omer, please specify what is impossible or hard to achieve with the current schema No problem with DB schema, please see my answer in engine-devel, I'm not sure you're directly cc'ed. The way I see it, it's a design issue. A disk is different from other devices as it can be attached to multiple VMs. I.e., the same Disk record in the database is associated with either 0 device records (a floating disk), 1 device record (a normal disk) or multiple device records (shared disk). The java object has a few properties that really belong to the disk (e.g., alias, size, wipeAfterDelete), some that belong to the device (plugged, readOnly in the near future) and some the belong to ALL the VMs it's attached to (e.g., vmNames). This way, the object is unusable - depending on which
Re: [Engine-devel] cannot attach ISO with latest master
Just pull the latest master - this patch was already merged. (Thanks Omer!) - Original Message - From: Dead Horse deadhorseconsult...@gmail.com To: Allon Mureinik amure...@redhat.com Cc: engine-devel@ovirt.org Sent: Saturday, May 18, 2013 12:30:08 AM Subject: Re: [Engine-devel] cannot attach ISO with latest master I attempted to test the patch however the result was engine compilation failure with the webadmin module. - DHC On Thu, May 16, 2013 at 11:22 AM, Allon Mureinik amure...@redhat.com wrote: The following patch (still pending review) should do the trick: http://gerrit.ovirt.org/#/c/14818/ From: Dead Horse deadhorseconsult...@gmail.com To: engine-devel@ovirt.org Sent: Thursday, May 16, 2013 5:31:23 PM Subject: Re: [Engine-devel] cannot attach ISO with latest master This occurs only when using Run Once to attach an ISO to a VM. It is still present in master as of this morning. It was reported recently by another user on the user list as well. - DHC On Mon, May 13, 2013 at 4:47 PM, Dead Horse deadhorseconsult...@gmail.com wrote: Cannot attach images from the iso storage domain with latest master. VDSM version is latest master as well Host = EL6.4 2013-05-13 16:41:02,184 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand] (ajp--127.0.0.1-8702-7) [5d889258] START, IsoPrefixVDSCommand( storagePoolId = 0cba78bd-f1b7-438f-afac-acd59fab92ae, ignoreFailoverLimit = false, compatabilityVersion = null), log id: a85d3c0 2013-05-13 16:41:02,196 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand] (ajp--127.0.0.1-8702-7) [5d889258] FINISH, IsoPrefixVDSCommand, return: /rhev/data-center/mnt/192.168.0.1:_ovirt_dalaran/d6276dc3-1714-4024-9b70-b7971ed5fe35/images/----, log id: a85d3c0 2013-05-13 16:41:02,328 WARN [org.ovirt.engine.core.bll.RunVmOnceCommand] (ajp--127.0.0.1-8702-7) [5d889258] CanDoAction of action RunVmOnce failed. Reasons:VAR__ACTION__RUN,VAR__TYPE__VM,ERROR_CANNOT_FIND_ISO_IMAGE_PATH - DHC ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] cannot attach ISO with latest master
The following patch (still pending review) should do the trick: http://gerrit.ovirt.org/#/c/14818/ - Original Message - From: Dead Horse deadhorseconsult...@gmail.com To: engine-devel@ovirt.org Sent: Thursday, May 16, 2013 5:31:23 PM Subject: Re: [Engine-devel] cannot attach ISO with latest master This occurs only when using Run Once to attach an ISO to a VM. It is still present in master as of this morning. It was reported recently by another user on the user list as well. - DHC On Mon, May 13, 2013 at 4:47 PM, Dead Horse deadhorseconsult...@gmail.com wrote: Cannot attach images from the iso storage domain with latest master. VDSM version is latest master as well Host = EL6.4 2013-05-13 16:41:02,184 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand] (ajp--127.0.0.1-8702-7) [5d889258] START, IsoPrefixVDSCommand( storagePoolId = 0cba78bd-f1b7-438f-afac-acd59fab92ae, ignoreFailoverLimit = false, compatabilityVersion = null), log id: a85d3c0 2013-05-13 16:41:02,196 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand] (ajp--127.0.0.1-8702-7) [5d889258] FINISH, IsoPrefixVDSCommand, return: /rhev/data-center/mnt/192.168.0.1:_ovirt_dalaran/d6276dc3-1714-4024-9b70-b7971ed5fe35/images/----, log id: a85d3c0 2013-05-13 16:41:02,328 WARN [org.ovirt.engine.core.bll.RunVmOnceCommand] (ajp--127.0.0.1-8702-7) [5d889258] CanDoAction of action RunVmOnce failed. Reasons:VAR__ACTION__RUN,VAR__TYPE__VM,ERROR_CANNOT_FIND_ISO_IMAGE_PATH - DHC ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST vs. UI validation
REST shouldn't have any validations (perhaps maybe only that the passed type is correct, etc. - Michael, correct me if I'm wrong). The real validations are in the backend, which both REST and the GUI invoke. Any validation the GUI does in addition to the backend is just a user-experience enhancement (e.g., if !@#^!^$) is not a valid DC name, there is no reason to send it to the backend). Vered - I disagree that this is by design. There is only one definition of what a correct value is, there should be no ambiguity about it[1] If the GUI prohibits you from a legal configuration - it should be fixed. if the backend allows an illegal configuration - a CDA should be added. My two cents - this is not OK, please open bugs (or even better - send patches!) for the specific issues. [1] Just to be clear, there is a difference between not being able to do something from the UI and having different validations. For example, there is no GUI for scanning a storage domain (http://www.ovirt.org/Features/Domain_Scan). I'd prefer having a GUI for that too, but not having it is just a missing capability, not a disambiguity with REST. - Original Message - From: Vered Volansky ve...@redhat.com To: Kari Whitcomb kari.whitc...@hp.com Cc: engine-devel@ovirt.org Sent: Tuesday, April 30, 2013 10:15:31 AM Subject: Re: [Engine-devel] REST vs. UI validation - Original Message - From: Kari Whitcomb kari.whitc...@hp.com To: engine-devel@ovirt.org Sent: Tuesday, April 30, 2013 1:19:00 AM Subject: [Engine-devel] REST vs. UI validation I've been making use of the oVirt REST api, and have noticed that in several cases the validation done for a REST request is different than what the admin UI does. It seems that the UI is generally more restrictive on the data it will accept than the backend. So you can set things up using the REST api that the UI wouldn't let you do. Two examples I've hit recently, both in the cluster policy (load balancing section): - Cluster load balancing policy duration - the UI requires a value between 1 and 100, but the REST api seems to let you set it to any integer. - Cluster load balancing high and low thresholds / max and min service levels - The UI restricts the high value to 51-90% and the low value to 10-50%. But the backend only requires that the values be 0-100% and that low can't be greater than high. So my question - is this intended behavior, or is it a bug that the validation is different? If similar validation should be done through both the UI and REST api, should the UI be less restrictive, or the backend more restrictive? This is the intended behaviour. The UI is often more restrictive than the api. By definition the api is more lenient that the UI. Regards, Vered Thanks, Kari ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] storage overallocation ratio
Hi Michal, apparentsize is the size that you perceive when working with the volume (i.e., ignoring sparseness etc.) while trusize is the size taken on the drive (i.e., taking sparseness etc. into account). DiskImage.getActualSize() should report the truesize. The end result is OK, since truesize overrides apparentsize in that command, but it's obviously wrong, and should be fixed [1]. [1] http://gerrit.ovirt.org/#/c/14176/ - Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: engine-devel@ovirt.org Sent: Saturday, April 20, 2013 11:13:04 PM Subject: [Engine-devel] storage overallocation ratio Hi, I was trying to find out how is this actually calculated. Doesn't look very straightforward…:) I'm curious about the following - vdsm reports something like truesize and apparentsize which IIUC should be distinct but then in engine, in backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/irsbroker/GetImageInfoVDSCommand.java it's written to the same engine property actual_size. That doesn't sound right. Can someone enlighten me please? Thanks, michal ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Location of findbugs filter.xml file
- Original Message - From: Mike Kolesnik mkole...@redhat.com To: engine-devel engine-devel@ovirt.org Cc: Oved Ourfalli ov...@redhat.com Sent: Thursday, April 18, 2013 5:10:39 PM Subject: Re: [Engine-devel] Location of findbugs filter.xml file - Original Message - - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 4:55:46 PM Subject: [Engine-devel] Location of findbugs filter.xml file Hi all, I sent a patch upstream to add findbugs filter that will filter out bug reports that we decided that are not bugs. We have a debate on whether to have the findbugs filter definition in the root pom.xml or to put it in the jenkins jobs repo and treat it as an external tool. I would like to hear opinions about what you think should be the proper location Putting it in the root pom.xml file will allow running filtered findbugs using maven, without the need to use jenkins, so I'd go with that approach. +1 Even better than that - each module can override the configuration with its own exceptions in its own pom file Thanks, Yair ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] build stuck on RunVmCommandTest
Real oddness. out of interest, can you run java -version and report the version here? - Original Message - From: Shireesh Anjal san...@redhat.com To: engine-devel@ovirt.org Sent: Wednesday, April 10, 2013 9:40:19 AM Subject: [Engine-devel] build stuck on RunVmCommandTest Hi, From last night onwards, my mvn build is getting stuck for a long time ( 30 minutes) on RunVmCommandTest Running org.ovirt.engine.core.bll.MoveDisksCommandTest Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec Running org.ovirt.engine.core.bll.RunVmCommandTest Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1,983.033 sec Running org.ovirt.engine.core.bll.lock.InMemoryLockManagerTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.ovirt.engine.core.bll.RemoveImageCommandTest The same issue is happening on one of my colleague's system as well. Any help in fixing this will be highly appreciated. Regards, Shireesh ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] build stuck on RunVmCommandTest
Einav had a similar issue yesterday with RemoveDiskTest (IIRC), which at first pointed me to the direction of Java 7, but this is unrelated. The root of all these problems is commit fd6835059f110f4e14d67c9d2d31aa786a822f4b (core: Locate data source in a loop) - now, whenever we have unmocked DAO calls (like in RunVmCommand), instead of failing them fast and silently, we'll get stuck in a loop. We need to see if we can offer a quick workaround, or perhaps revert this patch until we can offer such a solution. Juan, your input would be appreciates here. Thanks, Allon - Original Message - From: Shireesh Anjal san...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: engine-devel@ovirt.org Sent: Wednesday, April 10, 2013 11:15:40 AM Subject: Re: [Engine-devel] build stuck on RunVmCommandTest On 04/10/2013 01:39 PM, Allon Mureinik wrote: Real oddness. out of interest, can you run java -version and report the version here? shireesh@localhost ovirt-engine]$ java -version java version 1.7.0_09-icedtea OpenJDK Runtime Environment (fedora-2.3.4.fc18-x86_64) OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) - Original Message - From: Shireesh Anjal san...@redhat.com To: engine-devel@ovirt.org Sent: Wednesday, April 10, 2013 9:40:19 AM Subject: [Engine-devel] build stuck on RunVmCommandTest Hi, From last night onwards, my mvn build is getting stuck for a long time ( 30 minutes) on RunVmCommandTest Running org.ovirt.engine.core.bll.MoveDisksCommandTest Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec Running org.ovirt.engine.core.bll.RunVmCommandTest Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1,983.033 sec Running org.ovirt.engine.core.bll.lock.InMemoryLockManagerTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.ovirt.engine.core.bll.RemoveImageCommandTest The same issue is happening on one of my colleague's system as well. Any help in fixing this will be highly appreciated. Regards, Shireesh ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] build stuck on RunVmCommandTest
- Original Message - From: Juan Hernandez jhern...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: Shireesh Anjal san...@redhat.com, engine-devel@ovirt.org Sent: Wednesday, April 10, 2013 1:58:17 PM Subject: Re: [Engine-devel] build stuck on RunVmCommandTest On 04/10/2013 12:12 PM, Juan Hernandez wrote: On 04/10/2013 10:31 AM, Allon Mureinik wrote: Einav had a similar issue yesterday with RemoveDiskTest (IIRC), which at first pointed me to the direction of Java 7, but this is unrelated. The root of all these problems is commit fd6835059f110f4e14d67c9d2d31aa786a822f4b (core: Locate data source in a loop) - now, whenever we have unmocked DAO calls (like in RunVmCommand), instead of failing them fast and silently, we'll get stuck in a loop. We need to see if we can offer a quick workaround, or perhaps revert this patch until we can offer such a solution. Juan, your input would be appreciates here. As a workaround create /etc/ovirt-engine/engine.conf and add the following two lines: ENGINE_DB_CONNECTION_TIMEOUT=0 ENGINE_DB_CHECK_INTERVAL=0 Then the tests should run faster. This is a way to solve it: http://gerrit.ovirt.org/13782 Didn't get a chance to look at it before it was merged, but looks great. Thanks Juan! Thanks, Allon *From: *Shireesh Anjal san...@redhat.com *To: *Allon Mureinik amure...@redhat.com *Cc: *engine-devel@ovirt.org *Sent: *Wednesday, April 10, 2013 11:15:40 AM *Subject: *Re: [Engine-devel] build stuck on RunVmCommandTest On 04/10/2013 01:39 PM, Allon Mureinik wrote: Real oddness. out of interest, can you run java -version and report the version here? shireesh@localhost ovirt-engine]$ java -version java version 1.7.0_09-icedtea OpenJDK Runtime Environment (fedora-2.3.4.fc18-x86_64) OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) *From: *Shireesh Anjal san...@redhat.com *To: *engine-devel@ovirt.org *Sent: *Wednesday, April 10, 2013 9:40:19 AM *Subject: *[Engine-devel] build stuck on RunVmCommandTest Hi, From last night onwards, my mvn build is getting stuck for a long time ( 30 minutes) on RunVmCommandTest Running org.ovirt.engine.core.bll.MoveDisksCommandTest Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec *Running org.ovirt.engine.core.bll.RunVmCommandTest** **Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1,983.033 sec** *Running org.ovirt.engine.core.bll.lock.InMemoryLockManagerTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.ovirt.engine.core.bll.RemoveImageCommandTest The same issue is happening on one of my colleague's system as well. Any help in fixing this will be highly appreciated. Regards, Shireesh ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest?
When running [1] on this morning's master (commit hash eca9964, merged April 8th, 20:15 IST) I didn't notice any issues (built the entire project in ~3 minutes, backend took 27 seconds), but when running this test alone in eclipse it definitely took much longer. I'm guessing it lacks some mocking, which some earlier test is doing by mistake. Since JUnit does not enforce any ordering, we may be running our tests in a slightly different order (due to different maven/java/os minor versions, etc.), which makes the problem visible on your setup but not mine. I'll do somemore digging and see if I can pinpoint it. - Original Message - From: Einav Cohen eco...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Monday, April 8, 2013 6:35:47 PM Subject: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? Hi, When trying to compile oVirt (with tests - see [1]), my compilation seems to get stuck on RemoveSnapshotCommandTest (see [2] for test file full path, [3] for output). When eliminating this test (e.g. I removed [2] locally from my file-system), compilation (including tests) is completed successfully. Anyone else encountered this problem / any idea what the problem might be? Thanks, Einav [1] performed the following on the latest upstream: mvn clean mvn install -Pgwt-user,gwt-admin,all-langs -Dgwt.userAgent=gecko1_8 [2] ../backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/RemoveSnapshotCommandTest.java [3] last lines in compilation output: ... [INFO] [INFO] Building Backend Logic @Service bean 3.3.0-SNAPSHOT [INFO] ... Running org.ovirt.engine.core.bll.network.host.SetupNetworksHelperTest Tests run: 56, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.74 sec Running org.ovirt.engine.core.bll.network.cluster.GetAllNetworksByClusterIdQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec Running org.ovirt.engine.core.bll.network.cluster.AttachNetworkToVdsGroupCommandTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec Running org.ovirt.engine.core.bll.network.cluster.NetworkClusterValidatorTest Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec Running org.ovirt.engine.core.bll.network.cluster.GetVdsGroupsAndNetworksByNetworkIdQueryTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec Running org.ovirt.engine.core.bll.network.vm.GetVmInterfacesByVmIdQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec Running org.ovirt.engine.core.bll.network.vm.GetVmsAndNetworkInterfacesByNetworkIdQueryTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec Running org.ovirt.engine.core.bll.network.VmInterfaceManagerTest Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.321 sec Running org.ovirt.engine.core.bll.network.template.GetTemplateInterfacesByTemplateIdQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec Running org.ovirt.engine.core.bll.network.template.GetVmTemplatesAndNetworkInterfacesByNetworkIdQueryTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec Running org.ovirt.engine.core.bll.GetCommandsCompatibilityVersionsQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec Running org.ovirt.engine.core.bll.GetClustersWithPermittedActionQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec Running org.ovirt.engine.core.bll.RemoveSnapshotCommandTest [no more output after this point; waited ~20 minutes in this state before hitting Ctrl+C] ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest?
The last message would have been much more useful if I'd actually attached the link to my patch: http://gerrit.ovirt.org/#/c/13733/ Note that it is /not/ merge yet - review would be appreciated. - Original Message - From: Allon Mureinik amure...@redhat.com To: Einav Cohen eco...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, April 9, 2013 10:22:38 AM Subject: Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? OK, my guess is that test uses Mockito Matchers carelessly. I removed them, and on my setup I reduced the time it takes to run this test alone in eclipse from ~70 seconds to ~0.7 seconds (i.e., removed 99% of the runtime). Please check it solves the issue on your setup too. Thanks, Allon - Original Message - From: Allon Mureinik amure...@redhat.com To: Einav Cohen eco...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, April 9, 2013 9:39:41 AM Subject: Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? When running [1] on this morning's master (commit hash eca9964, merged April 8th, 20:15 IST) I didn't notice any issues (built the entire project in ~3 minutes, backend took 27 seconds), but when running this test alone in eclipse it definitely took much longer. I'm guessing it lacks some mocking, which some earlier test is doing by mistake. Since JUnit does not enforce any ordering, we may be running our tests in a slightly different order (due to different maven/java/os minor versions, etc.), which makes the problem visible on your setup but not mine. I'll do somemore digging and see if I can pinpoint it. - Original Message - From: Einav Cohen eco...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Monday, April 8, 2013 6:35:47 PM Subject: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? Hi, When trying to compile oVirt (with tests - see [1]), my compilation seems to get stuck on RemoveSnapshotCommandTest (see [2] for test file full path, [3] for output). When eliminating this test (e.g. I removed [2] locally from my file-system), compilation (including tests) is completed successfully. Anyone else encountered this problem / any idea what the problem might be? Thanks, Einav [1] performed the following on the latest upstream: mvn clean mvn install -Pgwt-user,gwt-admin,all-langs -Dgwt.userAgent=gecko1_8 [2] ../backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/RemoveSnapshotCommandTest.java [3] last lines in compilation output: ... [INFO] [INFO] Building Backend Logic @Service bean 3.3.0-SNAPSHOT [INFO] ... Running org.ovirt.engine.core.bll.network.host.SetupNetworksHelperTest Tests run: 56, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.74 sec Running org.ovirt.engine.core.bll.network.cluster.GetAllNetworksByClusterIdQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec Running org.ovirt.engine.core.bll.network.cluster.AttachNetworkToVdsGroupCommandTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec Running org.ovirt.engine.core.bll.network.cluster.NetworkClusterValidatorTest Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec Running org.ovirt.engine.core.bll.network.cluster.GetVdsGroupsAndNetworksByNetworkIdQueryTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec Running org.ovirt.engine.core.bll.network.vm.GetVmInterfacesByVmIdQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec Running org.ovirt.engine.core.bll.network.vm.GetVmsAndNetworkInterfacesByNetworkIdQueryTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec Running org.ovirt.engine.core.bll.network.VmInterfaceManagerTest Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.321 sec Running org.ovirt.engine.core.bll.network.template.GetTemplateInterfacesByTemplateIdQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec Running org.ovirt.engine.core.bll.network.template.GetVmTemplatesAndNetworkInterfacesByNetworkIdQueryTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec Running org.ovirt.engine.core.bll.GetCommandsCompatibilityVersionsQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec Running org.ovirt.engine.core.bll.GetClustersWithPermittedActionQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec Running org.ovirt.engine.core.bll.RemoveSnapshotCommandTest
Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest?
OK, patch is merged (thanks kind reviewers!) Einav - please check that this also solves the issue in /your/ setup and let us all know. Thanks, Allon - Original Message - From: Allon Mureinik amure...@redhat.com To: Einav Cohen eco...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, April 9, 2013 10:24:02 AM Subject: Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? The last message would have been much more useful if I'd actually attached the link to my patch: http://gerrit.ovirt.org/#/c/13733/ Note that it is /not/ merge yet - review would be appreciated. - Original Message - From: Allon Mureinik amure...@redhat.com To: Einav Cohen eco...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, April 9, 2013 10:22:38 AM Subject: Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? OK, my guess is that test uses Mockito Matchers carelessly. I removed them, and on my setup I reduced the time it takes to run this test alone in eclipse from ~70 seconds to ~0.7 seconds (i.e., removed 99% of the runtime). Please check it solves the issue on your setup too. Thanks, Allon - Original Message - From: Allon Mureinik amure...@redhat.com To: Einav Cohen eco...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, April 9, 2013 9:39:41 AM Subject: Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? When running [1] on this morning's master (commit hash eca9964, merged April 8th, 20:15 IST) I didn't notice any issues (built the entire project in ~3 minutes, backend took 27 seconds), but when running this test alone in eclipse it definitely took much longer. I'm guessing it lacks some mocking, which some earlier test is doing by mistake. Since JUnit does not enforce any ordering, we may be running our tests in a slightly different order (due to different maven/java/os minor versions, etc.), which makes the problem visible on your setup but not mine. I'll do somemore digging and see if I can pinpoint it. - Original Message - From: Einav Cohen eco...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Monday, April 8, 2013 6:35:47 PM Subject: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? Hi, When trying to compile oVirt (with tests - see [1]), my compilation seems to get stuck on RemoveSnapshotCommandTest (see [2] for test file full path, [3] for output). When eliminating this test (e.g. I removed [2] locally from my file-system), compilation (including tests) is completed successfully. Anyone else encountered this problem / any idea what the problem might be? Thanks, Einav [1] performed the following on the latest upstream: mvn clean mvn install -Pgwt-user,gwt-admin,all-langs -Dgwt.userAgent=gecko1_8 [2] ../backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/RemoveSnapshotCommandTest.java [3] last lines in compilation output: ... [INFO] [INFO] Building Backend Logic @Service bean 3.3.0-SNAPSHOT [INFO] ... Running org.ovirt.engine.core.bll.network.host.SetupNetworksHelperTest Tests run: 56, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.74 sec Running org.ovirt.engine.core.bll.network.cluster.GetAllNetworksByClusterIdQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec Running org.ovirt.engine.core.bll.network.cluster.AttachNetworkToVdsGroupCommandTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec Running org.ovirt.engine.core.bll.network.cluster.NetworkClusterValidatorTest Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec Running org.ovirt.engine.core.bll.network.cluster.GetVdsGroupsAndNetworksByNetworkIdQueryTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec Running org.ovirt.engine.core.bll.network.vm.GetVmInterfacesByVmIdQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec Running org.ovirt.engine.core.bll.network.vm.GetVmsAndNetworkInterfacesByNetworkIdQueryTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec Running org.ovirt.engine.core.bll.network.VmInterfaceManagerTest Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.321 sec Running org.ovirt.engine.core.bll.network.template.GetTemplateInterfacesByTemplateIdQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed
Re: [Engine-devel] Java 7, revisited again
After a week of positive reviews in gerrit, and no objections voiced here, patch was merged. piped catch clauses, here we come. - Original Message - From: Allon Mureinik amure...@redhat.com To: Kanagaraj kmayi...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Wednesday, April 3, 2013 10:06:34 AM Subject: Re: [Engine-devel] Java 7, revisited again Good point, thanks! Fixed up the patch and uploaded a new version. - Original Message - From: Kanagaraj kmayi...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Wednesday, April 3, 2013 7:23:16 AM Subject: Re: [Engine-devel] Java 7, revisited again On 04/02/2013 07:03 PM, Allon Mureinik wrote: Hola, A couple of weeks (months?) ago we discussed upgrading to Java 7.[1] Generally, there was a positive vibe about moving forward with technology, although we noted that this should not be done for common, compat and the GWT modules, searchbackend is also used by GWT, this needs to be excluded as well. Thanks, Kanagaraj under the limitation of the current GWT version we're using. Here's an initial suggestion for this upgrade: http://gerrit.ovirt.org/#/c/13519/ Areas handled and checked: 1. compilation (including GWT compilation)[2] 2. animal-sniffer validations for to makes sure that modules that aren't supposed to use JDK7 features really don't[2] 3. Running and making sure the UI still works :-) (checkstyle issues which Laslo pointed out in the original discussion were already solved in a different patch merged long ago) Sincerely, Allon and Alissa [1] http://lists.ovirt.org/pipermail/engine-devel/2012-December/003139.html [2] This includes, of course, purposely introducing Java 7 syntax and JDK 7 features to modules that aren't supposed to have them, and making sure that the build fails early, as expected, without having to add the -Pgwt-admin or -Pgwt-user profiles. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] CreateComputerAccount - do we really need it?
- Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Omer Frenkel ofren...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, March 17, 2013 12:12:21 PM Subject: Re: [Engine-devel] CreateComputerAccount - do we really need it? - Original Message - From: Omer Frenkel ofren...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, March 17, 2013 12:08:14 PM Subject: Re: [Engine-devel] CreateComputerAccount - do we really need it? - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: engine-devel@ovirt.org Sent: Sunday, March 17, 2013 12:01:37 PM Subject: [Engine-devel] CreateComputerAccount - do we really need it? Hi all, Do we need CreateComputerAccountCommand and its correspoding ldap broker LdapCreateComputerAccountCommand? is it exposed by any of the front-ends? (rest/user portal/webadmin)? No. git grep shows no-one uses it. Yair - are you sending a patch to remove it? Thanks, Yair ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposing Kiril nesenko as power user for ovirt engine tools
+1 - Original Message - From: Eyal Edri ee...@redhat.com To: infra in...@ovirt.org Cc: knesenko knese...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Thursday, February 7, 2013 10:39:47 AM Subject: [Engine-devel] Proposing Kiril nesenko as power user for ovirt engine tools Hi, I would like to propose kiril nesenko as 'jenkins power user' for ovirt engine tools. These tools indlude iso uploader, log collector, image uploader and others. Kiril is very involved in building and running Jenkins jobs on the rhevm product, and maintains package the ovirt tools currently. As part of being power user on jenkins.ovirt.org, he will create new jobs to build and release tools for the various OS supported. I vote +1 as i personally know kiril and he's experience. Thansk, Eyal. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [oVirt Jenkins] ovirt_engine_unit_tests - Build # 3216 - Still unstable!
Fixed in http://gerrit.ovirt.org/#/c/11413/. - Original Message - From: Eyal Edri ee...@redhat.com To: Gilad Chaplik gchap...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Friday, January 25, 2013 2:32:50 PM Subject: Re: [Engine-devel] [oVirt Jenkins] ovirt_engine_unit_tests - Build # 3216 - Still unstable! fyi, seems like this patch introduced new unit test failure, please check, http://gerrit.ovirt.org/gitweb?p=ovirt-engine.gita=commith=207cda518399d0474154d5c3a9c363bcc43b6a72 http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/3212/ Eyal. Infra team. - Original Message - From: Jenkins oVirt Server jenk...@ovirt.org To: ee...@redhat.com, engine-patc...@ovirt.org, ol...@redhat.com, yzasl...@redhat.com Sent: Friday, January 25, 2013 11:49:10 AM Subject: [oVirt Jenkins] ovirt_engine_unit_tests - Build # 3216 - Still unstable! Project: http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/ Build: http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/3216/ Build Number: 3216 Build Status: Still unstable Triggered By: Started by upstream project ovirt_engine build number 4,107, Started by upstream project ovirt_engine build number 4,109 - Changes Since Last Success: - Changes for Build #3212 [gerrit2] engine: consolidate VM and Poll queries Changes for Build #3213 [gerrit2] core:unlock_entity.sh is not finding a locked ... [gerrit2] core:unlock_entity.sh is not unlocking the vm... [emesika] core:If no power management configured or fails... Changes for Build #3214 Changes for Build #3215 [gerrit2] packaging: Starting ssh before adding host in AIO [gerrit2] packaging: Updated spec to use sdk version that supports ssl. [gerrit2] spelling: s/mster/master/ Changes for Build #3216 - Failed Tests: - 1 tests failed. FAILED: org.ovirt.engine.core.bll.GetAllVmPoolsAttachedToUserQueryTest.testQueryIsAUserQuery Error Message: A query tested for filtered access should not be an admin query Stack Trace: java.lang.AssertionError: A query tested for filtered access should not be an admin query at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.ovirt.engine.core.bll.AbstractUserQueryTest.testQueryIsAUserQuery(AbstractUserQueryTest.java:58) at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) at
[Engine-devel] JUnit 4.10 Upgrade
Hi guys, Earlier this week I upgraded ovirt-engine to use JUnit 4.10. The nifty new features can be found here: https://github.com/KentBeck/junit/blob/master/doc/ReleaseNotes4.10.md -Allon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Users] RHEVM 3.1 DB Schema diagram
- Original Message - From: Eli Mesika emes...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: users us...@ovirt.org, engine-devel engine-devel@ovirt.org Sent: Wednesday, December 5, 2012 12:51:20 PM Subject: Re: [Users] RHEVM 3.1 DB Schema diagram - Original Message - From: Allon Mureinik amure...@redhat.com To: Eli Mesika emes...@redhat.com Cc: users us...@ovirt.org, engine-devel engine-devel@ovirt.org Sent: Wednesday, December 5, 2012 9:21:34 AM Subject: Re: [Users] RHEVM 3.1 DB Schema diagram Nice! How are the names of the blocks generated? Some names strike me a bit there (e.g., images is in the storage_domains_static block). Auto-generated ... (nice work IMHO) That I get `-) I was asking if you understand where the names of the blocks are taken from, because I couldn't. - Original Message - From: Eli Mesika emes...@redhat.com To: users us...@ovirt.org, engine-devel engine-devel@ovirt.org Sent: Tuesday, December 4, 2012 7:12:28 PM Subject: [Users] RHEVM 3.1 DB Schema diagram Hi There were some requests on the users list to get our DB schema diagram. After looking a while for a tool for generating that , I have found the DBSchema tool. Please find attached the RHEVM 3.1 DB Schema diagram. I intend to get it into the oVirt site but currently it's too large and does not fit well. Regards Eli Mesika ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposal to add Shireesh Anjal as maintainer to engine-gluster
+1 - Original Message - From: Itamar Heim ih...@redhat.com To: engine-devel@ovirt.org Sent: Friday, November 30, 2012 1:28:51 PM Subject: [Engine-devel] Proposal to add Shireesh Anjal as maintainer to engine-gluster Shireesh has been working on the engine gluster support for the past year, covering patches and leading reviews of the various engine gluster patches. I'd like to propose a new sub-component of the engine for the gluster module, adding shireesh as its maintainer. Thanks, Itamar ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Revisiting Java7
- Original Message -
From: Itamar Heim ih...@redhat.com
To: Allon Mureinik amure...@redhat.com
Cc: engine-devel engine-devel@ovirt.org
Sent: Tuesday, December 4, 2012 1:40:10 AM
Subject: Re: [Engine-devel] Revisiting Java7
On 12/03/2012 04:03 PM, Allon Mureinik wrote:
Hi guys,
Earlier today, Java6 compatibility was broken
(http://gerrit.ovirt.org/#/c/9430/).
This was picked up on pretty quickly, and easily fixed
(http://gerrit.ovirt.org/#/c/9666/).
However, I think this is a good opportunity to revisit our policy
towards Java 7.
Currently, we have an odd setup, where we recommend running a
compiling /with/ Java 7 [1] but comply to Java 6 language level
[2] and JDK [3].
Inevitably, mistakes like the that happened today will happen.
I know we're holding back due to GWT issues, but looking forward to
oVirt 4.0, is Java 7 on our roadmap?
what was the GWT issue?
GWT 2.3 that we use doesn't support java 7 syntax.
The latest version, 2.5, doesn't either.
I'm not sure, however, this is a good reason to enforce the java 6 limitation
on the entire project (including backed, rest, etc.)
-Allon
[1] http://wiki.ovirt.org/Building_oVirt_engine#Installing_OpenJDK
[2] maven-compiler-plugin section in ${OVIRT_GIT}/pom.xml
[3] http://jenkins.ovirt.org/job/ovirt_engine_animal_sniffer_check/
P.S.
If you want to check that you aren't breaking Java/JDK 6
compatibility locally without installing java 6, you can run mvn
animal-sniffer:check. Note that animal sniffer analyzes binaries,
so this has to be done /after/ the project was built. Of course,
you can do this in a single line mvn install
animal-sniffer:check
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Users] RHEVM 3.1 DB Schema diagram
Nice! How are the names of the blocks generated? Some names strike me a bit there (e.g., images is in the storage_domains_static block). - Original Message - From: Eli Mesika emes...@redhat.com To: users us...@ovirt.org, engine-devel engine-devel@ovirt.org Sent: Tuesday, December 4, 2012 7:12:28 PM Subject: [Users] RHEVM 3.1 DB Schema diagram Hi There were some requests on the users list to get our DB schema diagram. After looking a while for a tool for generating that , I have found the DBSchema tool. Please find attached the RHEVM 3.1 DB Schema diagram. I intend to get it into the oVirt site but currently it's too large and does not fit well. Regards Eli Mesika ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Shipping settings.xml in oVirt engine's git repo (was RE: maven settings.xml in building ovirt engine wiki)
snipped Note that settings.xml isn't shifted with ovirt-engine, nor stored on ovirt-engine git repository. Therefore there is no real method to control its content expect updating the wiki page. Spinning off from the previous discussion - we can't really control the contents of settings.xml, but perhaps we can make them easier to get. Today, the flow is like this: 1. git clone - depends on gerrit.ovirt.org 2. wget settings.xml - depends on wiki.ovirt.org Suppose we ship settings.xml inside the configuration folder of ovirt (next to engine-code-format.xml and engine-commit-template.txt). Then you'll have to do: 1. git clone - depends on gerrit.ovirt.org 2. cp $OVIRT_GIT/config/settings.xml ~/.m2/ This may a bit simpler, and at the very least, when we update our code (e.g., to assume java7, *hint*), we can make all the changes in a single commit, and not have to update the code and then upload a file to the wiki. Comments? Feedback? -Allon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Shipping settings.xml in oVirt engine's git repo (was RE: maven settings.xml in building ovirt engine wiki)
- Original Message - From: Alon Bar-Lev alo...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: engine-devel@ovirt.org Sent: Wednesday, November 28, 2012 10:14:02 AM Subject: Re: [Engine-devel] Shipping settings.xml in oVirt engine's git repo (was RE: maven settings.xml in building ovirt engine wiki) - Original Message - From: Allon Mureinik amure...@redhat.com To: engine-devel@ovirt.org Sent: Wednesday, November 28, 2012 10:05:18 AM Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git repo (was RE: maven settings.xml in building ovirt engine wiki) snipped Note that settings.xml isn't shifted with ovirt-engine, nor stored on ovirt-engine git repository. Therefore there is no real method to control its content expect updating the wiki page. Spinning off from the previous discussion - we can't really control the contents of settings.xml, but perhaps we can make them easier to get. Today, the flow is like this: 1. git clone - depends on gerrit.ovirt.org 2. wget settings.xml - depends on wiki.ovirt.org Suppose we ship settings.xml inside the configuration folder of ovirt (next to engine-code-format.xml and engine-commit-template.txt). Then you'll have to do: 1. git clone - depends on gerrit.ovirt.org 2. cp $OVIRT_GIT/config/settings.xml ~/.m2/ This may a bit simpler, and at the very least, when we update our code (e.g., to assume java7, *hint*), we can make all the changes in a single commit, and not have to update the code and then upload a file to the wiki. Comments? Feedback? First thing... I don't like changing global state of a machine only because we require some setting... So copying ANYTHING to ~/.m2 is completely wrong in my opinion. There is -gs parameter for maven to specify alternate settings file, I strongly recommend people use it. Also, as far as I understand we only need some attributes defined... It is simple to use: $ export MAVEN_OPTS=-Dwhatever=value -Dwhatever=value Before executing eclipse or make... We can also integrate the environment variables idea into the maven build, instead of using properties use environment variables... then before executing build we: $ export JBOSS_HOME= $ export OVIRT_JDK_HOME= (optional) If anyone prefers/chooses to use settings.xml he can create his own... So there are so many options, the last option is to use settings.xml in my opinion... not that I against adding this template, but I first suggest we consider removing its usage completely :) Regards, Alon -Allon I'll rephrase. /today/ we provide an example of settings.xml in Building the oVirt Engine wiki page. People who understand maven will not overwrite their settings.xml with it, and people who don't have a comfortable quick start. I propose to supply this /exmaple/ in a more accessible place $OVIRT_GIT/config. People who didn't overwrite their existing .m2 file still won't, and people who did have an easier way of doing it. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] maven settings.xml in building ovirt engine wiki
Form my understanding, the issue was not maintaining multiple settings.xml
file, it was the fact that oVirt's wiki suggests a settings.xml file with /a
hard coded path/, which many potential community members will not have, simply
because they installed Java and/or JBoss in a different location.
Since in order to run JBoss properly you should already have $JBOSS_HOME and
$JAVA_HOME defined, the suggestion here was to reuse those values in
settings.xml too.
- Original Message -
From: Shireesh Anjal san...@redhat.com
To: Noam Slomianko nslom...@redhat.com
Cc: engine-devel@ovirt.org
Sent: Tuesday, November 27, 2012 11:07:11 AM
Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki
On Tuesday 27 November 2012 02:06 PM, Noam Slomianko wrote:
Oh, sorry.
Didnt notice it was sent to an ovit mailing list :D
so, my solution is:
create two different files (containing at least):
settings xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;
!-- PROFILES
--
localRepository{maven_home}/{repository}/localRepository
activeProfiles
activeProfileoVirtEnvSettings/activeProfile
/activeProfiles
profiles
profile
idoVirtEnvSettings/id
properties
jbossHome{jboss
location}/jbossHome
JAVA_HOME{java
location}/JAVA_HOME
gwt.userAgentgecko1_8/gwt.userAgent
/properties
/profile
/profiles
/settings
Between the two file you change:
- {jboss location}, self explanatory
- {java location}, only if they are of a different version
- {repository}, so you dont get conflicting packages
Of course they shouldn't be called Settings.xml
And then add a change script so its easy to switch via a soft link,
mine is:
if [ $1 = up ]
then
rm ~/.m2/settings.xml
ln -s ~/.m2/settingsUp.xml ~/.m2/settings.xml
echo changed jboss to upstream (1.7)
else
rm ~/.m2/settings.xml
ln -s ~/.m2/settingsDown.xml ~/.m2/settings.xml
echo changed jboss to downstream (1.6)
fi
Another trick is to use the --settings option of maven e.g.
mvn --settings ~/.m2/settingsUp.xml clean install -Pdep
- Original Message -
From: Noam Slomianko nslom...@redhat.com
To: Ofri Masad oma...@redhat.com
Cc: engine-devel@ovirt.org, Alissa Bonas abo...@redhat.com,
Laszlo Hornyak lhorn...@redhat.com
Sent: Tuesday, November 27, 2012 9:27:54 AM
Subject: Re: [Engine-devel] maven settings.xml in building ovirt
engine wiki
The Intranet is a black hole... documents can only go in never to
be found again.
I needed to go back 3 months in my browsing history to find this,
because why should it be found with keywords like upstream or
downstream :P
https://home.corp.redhat.com/wiki/working-downstream-and-upstream-parallel
Have fun,
Noam.
- Original Message -
From: Ofri Masad oma...@redhat.com
To: Laszlo Hornyak lhorn...@redhat.com, Noam Slomianko
nslom...@redhat.com
Cc: engine-devel@ovirt.org, Alissa Bonas abo...@redhat.com
Sent: Tuesday, November 27, 2012 9:10:48 AM
Subject: Re: [Engine-devel] maven settings.xml in building ovirt
engine wiki
Hi,
I can't seem to find it, but i think there was a wiki page about
working with multiple environments
(Upstream/Downstream/ZStream...)
Currently I'm using soft links to the setting.xml and .m2 repo.
That way i can jump safely and quickly between environments.
The paths are hard codded in the xml but i have few xml files
ponting to different jdk and jboss.
- Original Message -
From: Laszlo Hornyak lhorn...@redhat.com
To: Alissa Bonas abo...@redhat.com
Cc: engine-devel@ovirt.org
Sent: Monday, November 26, 2012 6:52:52 PM
Subject: Re: [Engine-devel] maven settings.xml in building ovirt
engine wiki
Hi,
That too could work, but once it already needs to be in the
settings.xml, why would you want another configuration file (like
.bashrc)?
- Original Message -
From: Alissa Bonas abo...@redhat.com
To: engine-devel@ovirt.org
Sent: Monday, November 26, 2012 10:15:14 AM
Subject: [Engine-devel] maven settings.xml in building ovirt
engine wiki
Hi,
In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine
The suggested maven settings.xml contains hardcoded paths to
jboss_home and java_home.
IMHO it's
[Engine-devel] Mocking EJB resources
Hi guys, Many of our classes use EJBUtils to access JBoss' resources/beans, such as TransactionManager, Schedular, LockingManager, etc. This is all fine and well, but it's a bit of a pain when testing those classes. Earlier today I merged a patch (thanks Laszlo, Michael K., Yair and Alissa for their comments!) that allows a streamlined, easier way of doing this, instead of having to muck around with mock objects (or mock around with muck objects, for that matter). The details can be found in the following wiki page: http://wiki.ovirt.org/wiki/MockEJBStrategyRule Enjoy, Allon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposal of Alon bar-lev as oVirt jenkins power user
- Original Message - From: Eyal Edri ee...@redhat.com To: infra in...@ovirt.org Cc: engine-devel@ovirt.org Sent: Thursday, November 22, 2012 4:16:37 PM Subject: [Engine-devel] Proposal of Alon bar-lev as oVirt jenkins power user Hi, To continue our new tradition of delegating power users for various oVirt sub project management in jenkins, I want to propose Alon bar-lev as power user for oVirt jenkins. Alon is well known within the oVirt community, and been contributing it in the past months. Alon has contributed code to many oVirt projects including massive re-factoring of the bootstrap process and numerous patches on other oVirt projects, Latest projects are otopi and ovirt-host-deploy. He is very technical with previous knowledge of Jenkins. as a power user he will be to: 1. create/update new jobs in jenkins.ovirt.org 2. run/trigger builds 3. run manual gerrit trigger jobs. i vote +1. please vote confidence with +1 or -1 for not. thanks, Eyal Edri. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel Eyal, could you please specify who this vote is open to? (for instance, when voting for new maintainers, only maintainers votes count) If my vote does count - +1, definitely. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposal to add Allon Mureinik as maintainer to engine core
Thanks for the vote of confidence! - Original Message - From: Itamar Heim ih...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, November 15, 2012 5:19:06 AM Subject: Re: [Engine-devel] Proposal to add Allon Mureinik as maintainer to engine core On 11/14/2012 06:12 AM, Itamar Heim wrote: Allon has worked on oVirt for the past 10 months. With 534 patches ranging from cleanups, to complex features like user level api and storage live migration. In addition, Allon has been instrumental in the number of patch reviews he has done. I'd like to propose Allon as a maintainer of engine core. per the resounding +1 (even if somewhat delayed by mail server issues), and no objections, added Allon as maintainer of engine core. dave - can you please take care of updating the web site? thanks, Itamar ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Running test suites on other OSs
Hi guys, After some on-and-off work over the last week (thanks Daniel!), as of this morning, engine's test suite runs successfully on a couple of non-fedora/rhel OSs[1]. The easier to get/build/test the code, the more likely we'll be to get more developers on board, so let's try and keep it this way. How to achieve this, in one sentence: Assumption is the mother of all screw-ups Some slightly more detailed pointers: 1. File separators: Remember File.separatorChar? good. 2. TimeZones: If your test implicitly assumes a time zone (i.e., has anything to do with date formatting, DST changes, etc.), set it explicitly - don't assume that everyone's env shares your timezone 3. org.junit.Assume is your friend Thanks, Allon [1] Don't ask, don't tell: http://gerrit.ovirt.org/#/c/8192/5 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Serial Execution of Async Tasks
- Original Message -
From: Michael Kublin mkub...@redhat.com
To: Allon Mureinik amure...@redhat.com
Cc: Eduardo Warszawski ewars...@redhat.com, Liron Aravot
lara...@redhat.com, Maor Lipchuk
mlipc...@redhat.com, engine-devel engine-devel@ovirt.org
Sent: Sunday, September 23, 2012 12:41:05 PM
Subject: Re: [Engine-devel] Serial Execution of Async Tasks
Hi guys,
As you may know the engine currently has the ability to
fire
an
SPM
task, and be asynchronously be woken-up when it ends.
This is great, but we found the for the Live Storage
Migration
feature we need something a bit complex - the ability to
have a
series of async tasks in a single control flow.
Here's my initial design for this, your comments and
criticism
would
be welcome:
http://wiki.ovirt.org/wiki/Features/Serial_Execution_of_Asynchronous_Tasks_Detailed_Design
-successful execution -
* CommandBase iterates over its SPMAsyncTaskHandlers -
when?
This is the new suggested format of executeCommand(). I'll
clarify
this too.
* If the second task is an HSM command (vs. SPM command), I
think you
should explain in the design how to handle such flows as
well.
HSM commands do not create AsyncTasks, as they do today - I
will
clarify this.
* Why do we need before task? can you give a concrete
example
of what
would you do in such a method.
Basically, /today/, command look like this:
executeCommand() {
doStuffInTheDB();
runVdsCommand(someCommand);
}
endSuccessfully() {
doMoreStuffInTheDB();
}
endWithFailure() {
doMoreStuffForFailureInTheDB();
}
In the new design, the entire doStuffInTheDB() should be
moved
to a
breforeTask of the (only) SPMAsyncTaskHandler.
- I see you added SPMAsyncTaskHandler, any reason not to use
SPMAsyncTasK to manage it own life-cycle?
Conserving today's design - The SPMAsyncTaskHandler is the
place to
add additional, non-SPM, logic around the SPM task execution,
like
CommandBase allows today.
- In the life-cycle managed by the SPMAsyncTaskHandler there
is a
step
'createTask - how to create the async task' can you please
elaborate
what are the options.
new [any type of async task]
(I cleaned thread a little.)
The following design and it is implementation
http://gerrit.ovirt.org/#/c/7956/
is bad.
I don't see any reason for creating a new SPMAsyncTaskHandler and
especially in the
way as it's done in patch.
The reason are following:
1. Performance , increased memory footprint, created CYCLIC
REFERENCE.
2. Readability and robust of code: the code which is written as
cyclic references is unreadable
and difficult for debug.
3. Why I need a generic implementation and changes all over whole
project because of
series of async commands, for me it is a private case?
This will occur all over the storage commands (which are the only usages of
tasks nowadys).
Moreover, async task handling is done at the Commandbase level (see the end*
methods) - instead of hacking it in X different places whenever we need it, I'd
prefer doing it once, properly.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Upstream git repo hung
FYI: http (/not/ https) also seems to work - Original Message - From: Kanagaraj Mayilsamy kmayi...@redhat.com To: Dhandapani dgo...@redhat.com Cc: engine-devel@ovirt.org Sent: Monday, September 17, 2012 9:17:38 AM Subject: Re: [Engine-devel] Upstream git repo hung I am facing the same issue, this happens when we use Anonymous Git. After that i tried with ssh, its working fine. Gerrit doesn't show the SSH/HTTPS url's for me even though I logged in. So you can manually modify the url's before doing a cherry-pick/fetch/checkout and try. Instead of git://gerrit... you can use ssh://username@gerrit... Regards Kanagaraj M - Original Message - From: Dhandapani dgo...@redhat.com To: engine-devel@ovirt.org Sent: Monday, September 17, 2012 11:42:30 AM Subject: [Engine-devel] Upstream git repo hung I got, fatal: The remote end hung up unexpectedly -- Regards, Dhandapani ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Serial Execution of Async Tasks
- Original Message -
From: Allon Mureinik amure...@redhat.com
To: Livnat Peer lp...@redhat.com
Cc: Eli Mesika emes...@redhat.com, Liron Aravot lara...@redhat.com,
Federico Simoncelli
fsimo...@redhat.com, engine-devel engine-devel@ovirt.org, Eduardo
Warszawski ewars...@redhat.com, Yeela
Kaplan ykap...@redhat.com
Sent: Tuesday, August 14, 2012 2:10:55 PM
Subject: Re: [Engine-devel] Serial Execution of Async Tasks
Hi guys,
Thanks for all your comments!
The correct response for many these points is to update the wiki.
I'm enclosing here the quick-and-dirty replies just to keep this
thread alive, and will update the wiki shortly.
See inline.
- Original Message -
From: Livnat Peer lp...@redhat.com
To: Allon Mureinik amure...@redhat.com
Cc: Eli Mesika emes...@redhat.com, Liron Aravot
lara...@redhat.com, Federico Simoncelli
fsimo...@redhat.com, engine-devel engine-devel@ovirt.org,
Eduardo Warszawski ewars...@redhat.com, Yeela
Kaplan ykap...@redhat.com
Sent: Sunday, August 12, 2012 9:39:23 AM
Subject: Re: [Engine-devel] Serial Execution of Async Tasks
On 10/08/12 03:40, Eli Mesika wrote:
- Original Message -
From: Allon Mureinik amure...@redhat.com
To: engine-devel engine-devel@ovirt.org
Cc: Eduardo Warszawski ewars...@redhat.com, Yeela Kaplan
ykap...@redhat.com, Federico Simoncelli
fsimo...@redhat.com, Liron Aravot lara...@redhat.com
Sent: Thursday, August 9, 2012 6:41:09 PM
Subject: [Engine-devel] Serial Execution of Async Tasks
Hi guys,
As you may know the engine currently has the ability to fire an
SPM
task, and be asynchronously be woken-up when it ends.
This is great, but we found the for the Live Storage Migration
feature we need something a bit complex - the ability to have a
series of async tasks in a single control flow.
Here's my initial design for this, your comments and criticism
would
be welcome:
http://wiki.ovirt.org/wiki/Features/Serial_Execution_of_Asynchronous_Tasks_Detailed_Design
Apart from the short explanation flow , since this is a
detailed
design , I would add
1) Class diagram
2) Flow diagram
Good idea, I'll see if I can jimmy something up.
+1, it would help understanding the flow.
- It looks like you chose not re-use/extend the ExecutionHandler
(the
entity used for building the tasks view exposed to the users).
It might be a good idea to keep the separation between the engine
Jobs
and the underlying vdsm tasks, but I want to make sure you are
familiar
with this mechanism and ruled it out with a reason. If this is the
case
please share why you decided not to use it.
As you said Jobs and Steps are pure engine entities - they can
contain no VDSM tasks, one VDSM task, or plausibly, in the future,
several tasks.
Even /today/, AsyncTasks and Jobs/Steps are two different kinds of
animals - I don't see any added value in mixing them together.
- how does this design survives a jboss restart? Can you please a
section in the wiki to explain that.
Basically, the way as a Command does today - the task is saved with
the executionIndex, and continues when the command is woken up.
I'll clarify this point in the wiki.
Added to the wiki.
-successful execution -
* CommandBase iterates over its SPMAsyncTaskHandlers - when?
This is the new suggested format of executeCommand(). I'll clarify
this too.
Added to the wiki.
* If the second task is an HSM command (vs. SPM command), I think
you
should explain in the design how to handle such flows as well.
HSM commands do not create AsyncTasks, as they do today - I will
clarify this.
Added to the wiki.
* Why do we need before task? can you give a concrete example of
what
would you do in such a method.
Basically, /today/, command look like this:
executeCommand() {
doStuffInTheDB();
runVdsCommand(someCommand);
}
endSuccessfully() {
doMoreStuffInTheDB();
}
endWithFailure() {
doMoreStuffForFailureInTheDB();
}
In the new design, the entire doStuffInTheDB() should be moved to a
breforeTask of the (only) SPMAsyncTaskHandler.
- I see you added SPMAsyncTaskHandler, any reason not to use
SPMAsyncTasK to manage it own life-cycle?
Conserving today's design - The SPMAsyncTaskHandler is the place to
add additional, non-SPM, logic around the SPM task execution, like
CommandBase allows today.
- In the life-cycle managed by the SPMAsyncTaskHandler there is a
step
'createTask - how to create the async task' can you please
elaborate
what are the options.
new [any type of async task]
Livnat
-Allon
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel
Re: [Engine-devel] Serial Execution of Async Tasks
- Original Message - From: Maor Lipchuk mlipc...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Allon Mureinik amure...@redhat.com, engine-devel engine-devel@ovirt.org, Eduardo Warszawski ewars...@redhat.com, Yeela Kaplan ykap...@redhat.com, Federico Simoncelli fsimo...@redhat.com, Liron Aravot lara...@redhat.com Sent: Thursday, August 16, 2012 8:27:33 PM Subject: Re: [Engine-devel] Serial Execution of Async Tasks On 08/16/2012 06:51 PM, Itamar Heim wrote: On 08/16/2012 03:21 PM, Maor Lipchuk wrote: On 08/14/2012 05:23 PM, Itamar Heim wrote: On 08/14/2012 02:35 PM, Maor Lipchuk wrote: How should we handle the auditLogMessages? Basically when a command ends it print an audit log. When we will start to use multiple tasks I assume user might get a bulk of audit logs which are actually related to the same action (when we fail for example the process will be create and delete). It might be a bit confusing for the user not to know which action is related to the operation I thought audit log gets written regardless of the transaction, so audit log appears as they happen? That is correct, The issue that I was referring to, is that now, with multiple tasks execution, we will get many audit logs which related to the same transaction but each one will be printed at a different time. I think that it might be confusing for the user to relate each audit log to the operation that was started. For example : User run an action that executes some tasks of create volumes, then the engine encounter a problem, and decide to rollback the operation and delete the volumes, in that case the engine will execute a delete task for the volumes, so user might see that delete of the volume (for example a snapshot) was initiated. Since those are asynchronous tasks, audit log will be printed in a different period of time and a user might not be aware what is the relation of those specific delete. async doesn't mean we don't print an audit log when we start it, and when we end it. so user would get the starting audit log when the task failed in your example. of course this may happen 2 hours after they started the task. as long as we can correlate the audit log to be part of the same job, i don't see the issue. yes, but if I understood correctly, we don't want to correlate the multiple tasks with the execution handler (which AFAIK handle the correlation id). I actually didn't mention this, but I don't see why not. What's I'd probably like to have is a log with Correlation ID xyzabc, step #3 starting/executing/ending Does this make any sense? I assume this issue can be addressed in a future phase, but maybe it is an issue that might worth to think about. Maybe we will need to use the correlation id of the Execution handler as Eli suggested or maybe add new states at CommandActionState? On 08/14/2012 02:10 PM, Allon Mureinik wrote: Hi guys, Thanks for all your comments! The correct response for many these points is to update the wiki. I'm enclosing here the quick-and-dirty replies just to keep this thread alive, and will update the wiki shortly. See inline. - Original Message - From: Livnat Peer lp...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: Eli Mesika emes...@redhat.com, Liron Aravot lara...@redhat.com, Federico Simoncelli fsimo...@redhat.com, engine-devel engine-devel@ovirt.org, Eduardo Warszawski ewars...@redhat.com, Yeela Kaplan ykap...@redhat.com Sent: Sunday, August 12, 2012 9:39:23 AM Subject: Re: [Engine-devel] Serial Execution of Async Tasks On 10/08/12 03:40, Eli Mesika wrote: - Original Message - From: Allon Mureinik amure...@redhat.com To: engine-devel engine-devel@ovirt.org Cc: Eduardo Warszawski ewars...@redhat.com, Yeela Kaplan ykap...@redhat.com, Federico Simoncelli fsimo...@redhat.com, Liron Aravot lara...@redhat.com Sent: Thursday, August 9, 2012 6:41:09 PM Subject: [Engine-devel] Serial Execution of Async Tasks Hi guys, As you may know the engine currently has the ability to fire an SPM task, and be asynchronously be woken-up when it ends. This is great, but we found the for the Live Storage Migration feature we need something a bit complex - the ability to have a series of async tasks in a single control flow. Here's my initial design for this, your comments and criticism would be welcome: http://wiki.ovirt.org/wiki/Features/Serial_Execution_of_Asynchronous_Tasks_Detailed_Design Apart from the short explanation flow , since this is a detailed design , I would add 1) Class diagram 2) Flow diagram Good idea, I'll see if I can jimmy something up. +1, it would help understanding the flow. - It looks like you chose not re-use/extend the ExecutionHandler (the entity used for building the tasks view exposed
Re: [Engine-devel] Serial Execution of Async Tasks
- Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Eli Mesika emes...@redhat.com Cc: Liron Aravot lara...@redhat.com, Federico Simoncelli fsimo...@redhat.com, engine-devel engine-devel@ovirt.org, Eduardo Warszawski ewars...@redhat.com, Yeela Kaplan ykap...@redhat.com, Allon Mureinik amure...@redhat.com Sent: Friday, August 10, 2012 10:48:16 PM Subject: Re: [Engine-devel] Serial Execution of Async Tasks - Original Message - From: Eli Mesika emes...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: Liron Aravot lara...@redhat.com, Federico Simoncelli fsimo...@redhat.com, engine-devel engine-devel@ovirt.org, Eduardo Warszawski ewars...@redhat.com, Yeela Kaplan ykap...@redhat.com Sent: Friday, August 10, 2012 3:40:48 AM Subject: Re: [Engine-devel] Serial Execution of Async Tasks - Original Message - From: Allon Mureinik amure...@redhat.com To: engine-devel engine-devel@ovirt.org Cc: Eduardo Warszawski ewars...@redhat.com, Yeela Kaplan ykap...@redhat.com, Federico Simoncelli fsimo...@redhat.com, Liron Aravot lara...@redhat.com Sent: Thursday, August 9, 2012 6:41:09 PM Subject: [Engine-devel] Serial Execution of Async Tasks Hi guys, As you may know the engine currently has the ability to fire an SPM task, and be asynchronously be woken-up when it ends. This is great, but we found the for the Live Storage Migration feature we need something a bit complex - the ability to have a series of async tasks in a single control flow. Here's my initial design for this, your comments and criticism would be welcome: http://wiki.ovirt.org/wiki/Features/Serial_Execution_of_Asynchronous_Tasks_Detailed_Design Apart from the short explanation flow , since this is a detailed design , I would add 1) Class diagram 2) Flow diagram +1 I am also interested to get a flow how a task is created (i.e - replacement of ConcreateCreateTask) - but this will be handled in what Eli has asked for. In addition, you have two titles of Successful Execution. Fixed. At compensate - see how revertTasks currently behaves. Also read - http://wiki.ovirt.org/wiki/Main_Page/features/RunningCommandsOnEndActionFailure This is the work I did for CloneVmFromSnapshot - not saying it's perfect - but you should have an infrastructure/pattern to rollback not just via spmRevertTask but also using an engine command. This is what the endWithFailure does - or am I missing your point? Yair -Allon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Serial Execution of Async Tasks
- Original Message - From: Eli Mesika emes...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: Eduardo Warszawski ewars...@redhat.com, Yeela Kaplan ykap...@redhat.com, Federico Simoncelli fsimo...@redhat.com, Liron Aravot lara...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Friday, August 10, 2012 3:40:48 AM Subject: Re: [Engine-devel] Serial Execution of Async Tasks - Original Message - From: Allon Mureinik amure...@redhat.com To: engine-devel engine-devel@ovirt.org Cc: Eduardo Warszawski ewars...@redhat.com, Yeela Kaplan ykap...@redhat.com, Federico Simoncelli fsimo...@redhat.com, Liron Aravot lara...@redhat.com Sent: Thursday, August 9, 2012 6:41:09 PM Subject: [Engine-devel] Serial Execution of Async Tasks Hi guys, As you may know the engine currently has the ability to fire an SPM task, and be asynchronously be woken-up when it ends. This is great, but we found the for the Live Storage Migration feature we need something a bit complex - the ability to have a series of async tasks in a single control flow. Here's my initial design for this, your comments and criticism would be welcome: http://wiki.ovirt.org/wiki/Features/Serial_Execution_of_Asynchronous_Tasks_Detailed_Design Apart from the short explanation flow , since this is a detailed design , I would add 1) Class diagram Done 2) Flow diagram -Allon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Any way to break the dao_unit_tests up?
- Original Message - From: Mike Kolesnik mkole...@redhat.com To: Shireesh Anjal san...@redhat.com Cc: engine-devel@ovirt.org, infra in...@ovirt.org Sent: Tuesday, August 21, 2012 9:43:23 AM Subject: Re: [Engine-devel] Any way to break the dao_unit_tests up? - Original Message - On Monday 20 August 2012 11:16 AM, Mike Kolesnik wrote: - Original Message - The DAO unit tests take twice as long as the rest of the test to run is there any way to break them up into two pieces? It will not be easy.. The way the tests are built today is with DB-unit. DB-unit allows to have an XML file with predefined data (called fixtures) which is used to recreate the DB data each time a test-class is run. This is all fine, except that in our tests there are (at least) 2 issues: 1. The same fixtures.xml file is used in all DAO tests. 2. Some DAOs require fixtures for several tables. Now, we could fix issue #1 by splitting the fixtures file into smaller files, each relating to only one table, which would allow us to run these tests in parallel on the same DB. Issue #2 would require to figure out which tests require several fixtures, and have them run isolated from the other tests which require only a single table. A simpler solution could be to have the tests run each on it's own db schema (or it's own db) which eliminates the dependencies and allows to run all in parallel, but is a bit more complicated to maintain (we would need some script that generates these schemas/dbs for tests automatically) and keeping multiple schemas up to date would also require CPU time. This is speaking in terms of the tests themselves, without considering the build process itself. There are two issues here: 1) DB connection is created during initialization of every test case, and destroyed at the end of each test case execution 2) The fixtures data is inserted during initialization of every test case I think both of these can be resolved by - creating the test data only during initialization of the first test case, which will include creating the connection (with auto-commit = false), inserting fixtures data and committing it - rolling back any changes done to the database during test case execution in the tearDown method I just tried this in two phases. Using the same connection across all test cases brought down the dao unit tests run time from 4:42.683s to 1:07.628s, and inserting the fixtures data only once further brought it down to just 22.295s ! (on my local development machine) I've just sent a patch with these changes: http://gerrit.ovirt.org/7336 Patch merged, Thanks Shireesh for the contribution, now the DAO tests are super fast! 20-something seconds to run DAO tests? awesome! Kudos, Shireesh! -- Thanks Robert Middleswarth @rmiddle (twitter/IRC) ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Serial Execution of Async Tasks
Hi guys,
Thanks for all your comments!
The correct response for many these points is to update the wiki.
I'm enclosing here the quick-and-dirty replies just to keep this thread alive,
and will update the wiki shortly.
See inline.
- Original Message -
From: Livnat Peer lp...@redhat.com
To: Allon Mureinik amure...@redhat.com
Cc: Eli Mesika emes...@redhat.com, Liron Aravot lara...@redhat.com,
Federico Simoncelli
fsimo...@redhat.com, engine-devel engine-devel@ovirt.org, Eduardo
Warszawski ewars...@redhat.com, Yeela
Kaplan ykap...@redhat.com
Sent: Sunday, August 12, 2012 9:39:23 AM
Subject: Re: [Engine-devel] Serial Execution of Async Tasks
On 10/08/12 03:40, Eli Mesika wrote:
- Original Message -
From: Allon Mureinik amure...@redhat.com
To: engine-devel engine-devel@ovirt.org
Cc: Eduardo Warszawski ewars...@redhat.com, Yeela Kaplan
ykap...@redhat.com, Federico Simoncelli
fsimo...@redhat.com, Liron Aravot lara...@redhat.com
Sent: Thursday, August 9, 2012 6:41:09 PM
Subject: [Engine-devel] Serial Execution of Async Tasks
Hi guys,
As you may know the engine currently has the ability to fire an
SPM
task, and be asynchronously be woken-up when it ends.
This is great, but we found the for the Live Storage Migration
feature we need something a bit complex - the ability to have a
series of async tasks in a single control flow.
Here's my initial design for this, your comments and criticism
would
be welcome:
http://wiki.ovirt.org/wiki/Features/Serial_Execution_of_Asynchronous_Tasks_Detailed_Design
Apart from the short explanation flow , since this is a detailed
design , I would add
1) Class diagram
2) Flow diagram
Good idea, I'll see if I can jimmy something up.
+1, it would help understanding the flow.
- It looks like you chose not re-use/extend the ExecutionHandler (the
entity used for building the tasks view exposed to the users).
It might be a good idea to keep the separation between the engine
Jobs
and the underlying vdsm tasks, but I want to make sure you are
familiar
with this mechanism and ruled it out with a reason. If this is the
case
please share why you decided not to use it.
As you said Jobs and Steps are pure engine entities - they can contain no VDSM
tasks, one VDSM task, or plausibly, in the future, several tasks.
Even /today/, AsyncTasks and Jobs/Steps are two different kinds of animals - I
don't see any added value in mixing them together.
- how does this design survives a jboss restart? Can you please a
section in the wiki to explain that.
Basically, the way as a Command does today - the task is saved with the
executionIndex, and continues when the command is woken up.
I'll clarify this point in the wiki.
-successful execution -
* CommandBase iterates over its SPMAsyncTaskHandlers - when?
This is the new suggested format of executeCommand(). I'll clarify this too.
* If the second task is an HSM command (vs. SPM command), I think you
should explain in the design how to handle such flows as well.
HSM commands do not create AsyncTasks, as they do today - I will clarify this.
* Why do we need before task? can you give a concrete example of what
would you do in such a method.
Basically, /today/, command look like this:
executeCommand() {
doStuffInTheDB();
runVdsCommand(someCommand);
}
endSuccessfully() {
doMoreStuffInTheDB();
}
endWithFailure() {
doMoreStuffForFailureInTheDB();
}
In the new design, the entire doStuffInTheDB() should be moved to a breforeTask
of the (only) SPMAsyncTaskHandler.
- I see you added SPMAsyncTaskHandler, any reason not to use
SPMAsyncTasK to manage it own life-cycle?
Conserving today's design - The SPMAsyncTaskHandler is the place to add
additional, non-SPM, logic around the SPM task execution, like CommandBase
allows today.
- In the life-cycle managed by the SPMAsyncTaskHandler there is a
step
'createTask - how to create the async task' can you please elaborate
what are the options.
new [any type of async task]
Livnat
-Allon
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Unifying (parts of) commit templates.
- Original Message - From: Livnat Peer lp...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, August 9, 2012 11:54:38 AM Subject: Re: [Engine-devel] Unifying (parts of) commit templates. On 09/08/12 11:52, Itamar Heim wrote: On 08/09/2012 09:11 AM, Livnat Peer wrote: On 09/08/12 00:41, Doron Fediuck wrote: Hi All, It seems that for commit subjects, vdsm is using a general concept of- BZ#??? some message I'd like to suggest adopting it to the engine template we use today- BZ#??? core | restapi | tools | history | engine | userportal | webadmin: short summary under 50 chars This may help us write some scripts which will work both for vdsm and engine BZs. +1 with a small change - adding a \n after the bz number - wouldn't this kill git shortlog? patch short summary must be in first line iirc yes it will. +1 for Doron's initial proposal +1. Also, while we're at it, a wiki explaining the correct way to use this template would be great. I know, it's pretty straight forward, but new contributed may get confused as to the distinction between core and engine, or how to mark a vertical patch that fixes a UI dialog and the backend logic behind it (with a coma between components? a slash? a pipe?) BZ#??? core | restapi | tools | history | engine | userportal | webadmin: short summary under 50 chars Long description of what this commit is about Livnat Doron. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Serial Execution of Async Tasks
Hi guys, As you may know the engine currently has the ability to fire an SPM task, and be asynchronously be woken-up when it ends. This is great, but we found the for the Live Storage Migration feature we need something a bit complex - the ability to have a series of async tasks in a single control flow. Here's my initial design for this, your comments and criticism would be welcome: http://wiki.ovirt.org/wiki/Features/Serial_Execution_of_Asynchronous_Tasks_Detailed_Design -Allon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Reminder - common
Roy is working on a way to prevent this from happening: http://gerrit.ovirt.org/#/c/6785/ - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, July 31, 2012 10:58:37 AM Subject: [Engine-devel] Reminder - common Hi, Please do not insert projects to pom.xml which do not compile by both engine core and gwt. Thanks, Yair ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Conformining to Java 6 using Animal Sniffer
Hi guys, As you may recall, a couple of weeks ago it was decided (in this mailing list), that we want to preserve backwards compatibility to Java 6. Instead of having to install JDK 6 alongside your Java 7, you can now use Animal Sniffer[1] to verify this. Simply run mvn animal-sniffer:check before you push, and assuming the build is successful, you're good to go. Note: Animal Sniffer takes about a minute to run, so it was NOT added by default to the install target. It is still your responsibility to verify backwards compatibility of you code, this is just a convenient way of doing it. Many thanks to Juan and Doron for their insights and reviews for this patch. -Allon [1] http://mojo.codehaus.org/animal-sniffer-maven-plugin/ ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Building ovirt engine instructions
Also, if you're using Eclipse Juno, you want to take a look at this gerrit
topic:
http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:eclipse-juno-support,n,z
I found out the hard way Juno is a tad over-strict when it comes to parsing
poms, and this may save you some trouble
- Original Message -
From: Allon Mureinik amure...@redhat.com
To: George Costea george.cos...@netapp.com
Cc: engine-devel@ovirt.org
Sent: Friday, July 27, 2012 9:04:11 PM
Subject: Re: [Engine-devel] Building ovirt engine instructions
Just had to reinstall and reconfigure Eclipse myself due to a yum
upgrade misshap (kids, don't try this at home :-)), so here's some
insight on the process.
- Original Message -
From: George Costea george.cos...@netapp.com
To: Yair Zaslavsky yzasl...@redhat.com, engine-devel@ovirt.org
Sent: Friday, July 27, 2012 2:03:14 PM
Subject: Re: [Engine-devel] Building ovirt engine instructions
I get to the step that reads, Change project settings to Resolve
compilation errors.
After completing the first 3 steps below:
restapi-definition - project - properties - java build path
-
source - add source folder - target/generated-sources/xjc
ack.
webadmin - project - properties - java build path - source
-
add source folder-
target/generated-sources/{annotations,gwt,test-annotations}
Eclipse Juno did this automatically for me, but yes, if it wasn't
added automatically, you should add it.
frontend - project - properties - java build path - source
-
add source folder- target/generated-sources/gwt
Same as above.
I am left with 181 Errors. I then try the 4th step:
frontend - project - properties - Projects - Add - webadmin
This introduces 5 errors stating, A cycle was detected in the
build
path of project
'frontend'/'gwt-common'/'uicommonweb'/'userportal'/'webadmin'. The
cycle consists of projects {frontend, webadmin, uicommonweb,
gwt-common, userportal}
Indeed - this step seems wrong. I will remove it from the wiki page.
I then try the 5th step:
sharedgwt - project - properties - Projects - Add - common
It was indeed removed - skip to the next stage regarding uicompat.
Also, there are steps missing (I'll add them to the wiki):
gwt-extensios - add anything under target/generated-sources
gwt-common - add target/generated-sources/annotations; also add
depdendency on uicommon-web, common and compat
uicompat - add target/generated-sources/annotations
generic-api - add dependencies on common, compat and utils
But there is no sharedgwt project. Does this provide enough
detail?
-Original Message-
From: engine-devel-boun...@ovirt.org
[mailto:engine-devel-boun...@ovirt.org] On Behalf Of Yair Zaslavsky
Sent: Friday, July 27, 2012 1:13 AM
To: engine-devel@ovirt.org
Subject: Re: [Engine-devel] Building ovirt engine instructions
On 07/27/2012 12:58 AM, Costea, George wrote:
It works fine from the CLI (I was running out of memory). I'm
still getting an issue with Eclipse though about a cycle being
detected from the build path.
Please elaborate on this cyclic dependency (I guess this is the
issue,
right?)
What matters the most is that you can build from CLI.
Some of the oVirt engine mantainers do not build from Eclipse (I
personally find the maven plugin to be too buggy) , but it's a
matter of personal preference. We will try to help you regardlessly
Yair
-Original Message-
From: Oved Ourfalli [mailto:ov...@redhat.com]
Sent: Thursday, July 26, 2012 5:34 PM
To: Costea, George
Cc: engine-devel@ovirt.org
Subject: Re: [Engine-devel] Building ovirt engine instructions
- Original Message -
From: George Costeageorge.cos...@netapp.com
To: engine-devel@ovirt.org
Sent: Thursday, July 26, 2012 11:33:04 PM
Subject: [Engine-devel] Building ovirt engine instructions
I think the wiki page (
http://wiki.ovirt.org/wiki/Building_Ovirt_Engine ) to build the
ovirt
engine is outdated. When I reach the deploy section, it always
fails.
Is there an update to get the ear file deployed?
Can you elaborate more on the issue? What's the exact
failure/error
you see when deploying?
The Eclipse instructions (
http://wiki.ovirt.org/wiki/Building_Ovirt_Engine/IDE ) also seem
to
be out of date. When I follow the steps to change project
settings, I
get an error stating that “A cycle was detected in the build
path
of
the project...” Could we get an update on this too?
Thanks,
George
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel
[Engine-devel] No more forking in bll tests
Hi guys, This morning a couple of patches were merged to remove Gluster's dependency on PowerMock (Shireesh and Selvasundaram - thanks for your commitment and involvement!). Consequentially, there is no more need to fork bll's tests, so that too was removed. Currently, bll's full build runs in just under 3 minutes (on my machine), and just under a minute for the test suite alone, without re-compiling the entire module. Let's keep it this way - It is /NOT/ ok to add new usages of PowerMock. The few leftoveres that are still there are being examined, and the PowerMock dependency will be removed once they are also gone. Here's to speedy builds and agile development, Allon P.S. A mega-huge thanks to everyone that was involved in this effort - Laszlo, Mike, Omer, Shireesh, Selvasundaram, and anyone else I may have forgotten by mistake. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] java 1.6 compatibility no more?
- Original Message - From: Itamar Heim ih...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: Livnat Peer lp...@redhat.com, Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org, Michael Kublin mkub...@redhat.com Sent: Monday, July 23, 2012 8:43:02 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/23/2012 08:29 AM, Allon Mureinik wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: Livnat Peer lp...@redhat.com, Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org, Michael Kublin mkub...@redhat.com Sent: Sunday, July 22, 2012 7:41:00 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/22/2012 07:38 PM, Allon Mureinik wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: Itamar Heim ih...@redhat.com, Michael Kublin mkub...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org Sent: Sunday, July 22, 2012 9:50:47 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 21/07/12 15:15, Itamar Heim wrote: On 07/19/2012 03:34 PM, Ayal Baron wrote: - Original Message - On Jul 19, 2012, at 14:14 , Livnat Peer wrote: On 19/07/12 14:41, Juan Hernandez wrote: On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: On 07/19/2012 02:31 PM, Vojtech Szocs wrote: Don't we need that (the source part) to avoid Java 7 syntax in GWT code? That's a very good point. In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail. So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however. We could do something like this: - let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6) (note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code) What do you think? Vojtech +1 - I really like this idea! +1 from me as well. There are two calls to make when it comes to JDK7 (regardless of GWT - excuse me for taking this discussion some steps backwards) 1. Are we running with JRE 7? The answer is yes we agreed on that a few months ago. 2. Are we using code syntax which is incompatible with JDK6? I think the answer to the above should be no (at least for now - maybe until the next ovirt release?). +1 exactly. Why starting with jdk6 incompatible constructs unless there is a good (or at least any) reason for them… +1 +1 - there is merit keeping backward compatibility to allow comparing behavior while java 7 is still young. Since no one objected, we'll go with JDK6 syntax compatibility for Now. I'm a very small fan of enforcing policy by reviewers. Not that the community reviews aren't great - but people miss things. Here's my take on Maven's enforcer plugin to actually verify we aren't compiling with JDK 7: http://gerrit.ovirt.org/#/c/6523 we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side. I don't understand this suggestion. What you're saying is that you can compile with whatever JDK you want, but: - it won't compile with JDKs prior to 6, since we're using 6's features. - you aren't allowed to use JDK 7 features, and if you do, you'll get an email from jenkins that you broke something and must fix it. To me, this sounds a lot like enforcing JDK 6 compatibility. its preserving jdk 6 compatibility for a few more months, not enforcing to use jdk 6 compiler. Fair enough. /today/ if have way too many (i.e., 0) jenkins breaks, a lot of which could be avoided by not running with -DskipTetst or making sure to run with -Penable-dao-tests. I fear this suggestion will just add to this noise, and could easily be avoided. jenkins breaks should be visible at patch level prior to commit, something we are trying to resolve by adding more hardware to allow running the various tests at patch level rather than post commit only. I agree that this is an excellent goal, but I maintain that this is an uncomfortable way to work. I would still like a way to check, on my own machine, as part of my compilation process, that I'm not doing anything I shouldn't. Here's my second take on the issue, using Animal Sniffer (http
Re: [Engine-devel] java 1.6 compatibility no more?
- Original Message - From: Juan Hernandez jhern...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: Itamar Heim ih...@redhat.com, engine-devel@ovirt.org Sent: Monday, July 23, 2012 1:22:37 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/23/2012 11:46 AM, Allon Mureinik wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: Livnat Peer lp...@redhat.com, Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org, Michael Kublin mkub...@redhat.com Sent: Monday, July 23, 2012 8:43:02 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/23/2012 08:29 AM, Allon Mureinik wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: Livnat Peer lp...@redhat.com, Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org, Michael Kublin mkub...@redhat.com Sent: Sunday, July 22, 2012 7:41:00 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/22/2012 07:38 PM, Allon Mureinik wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: Itamar Heim ih...@redhat.com, Michael Kublin mkub...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org Sent: Sunday, July 22, 2012 9:50:47 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 21/07/12 15:15, Itamar Heim wrote: On 07/19/2012 03:34 PM, Ayal Baron wrote: - Original Message - On Jul 19, 2012, at 14:14 , Livnat Peer wrote: On 19/07/12 14:41, Juan Hernandez wrote: On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: On 07/19/2012 02:31 PM, Vojtech Szocs wrote: Don't we need that (the source part) to avoid Java 7 syntax in GWT code? That's a very good point. In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail. So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however. We could do something like this: - let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6) (note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code) What do you think? Vojtech +1 - I really like this idea! +1 from me as well. There are two calls to make when it comes to JDK7 (regardless of GWT - excuse me for taking this discussion some steps backwards) 1. Are we running with JRE 7? The answer is yes we agreed on that a few months ago. 2. Are we using code syntax which is incompatible with JDK6? I think the answer to the above should be no (at least for now - maybe until the next ovirt release?). +1 exactly. Why starting with jdk6 incompatible constructs unless there is a good (or at least any) reason for them… +1 +1 - there is merit keeping backward compatibility to allow comparing behavior while java 7 is still young. Since no one objected, we'll go with JDK6 syntax compatibility for Now. I'm a very small fan of enforcing policy by reviewers. Not that the community reviews aren't great - but people miss things. Here's my take on Maven's enforcer plugin to actually verify we aren't compiling with JDK 7: http://gerrit.ovirt.org/#/c/6523 we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side. I don't understand this suggestion. What you're saying is that you can compile with whatever JDK you want, but: - it won't compile with JDKs prior to 6, since we're using 6's features. - you aren't allowed to use JDK 7 features, and if you do, you'll get an email from jenkins that you broke something and must fix it. To me, this sounds a lot like enforcing JDK 6 compatibility. its preserving jdk 6 compatibility for a few more months, not enforcing to use jdk 6 compiler. Fair enough. /today/ if have way too many (i.e., 0) jenkins breaks, a lot of which could be avoided by not running with -DskipTetst or making sure to run with -Penable-dao-tests. I fear this suggestion will just add to this noise, and could easily be avoided. jenkins breaks should be visible at patch level prior to commit, something we are trying to resolve by adding more hardware to allow running the various tests
Re: [Engine-devel] java 1.6 compatibility no more?
- Original Message - From: Juan Hernandez jhern...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: engine-devel@ovirt.org Sent: Monday, July 23, 2012 2:31:24 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/23/2012 01:02 PM, Allon Mureinik wrote: - Original Message - From: Juan Hernandez jhern...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: Itamar Heim ih...@redhat.com, engine-devel@ovirt.org Sent: Monday, July 23, 2012 1:22:37 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/23/2012 11:46 AM, Allon Mureinik wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: Livnat Peer lp...@redhat.com, Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org, Michael Kublin mkub...@redhat.com Sent: Monday, July 23, 2012 8:43:02 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/23/2012 08:29 AM, Allon Mureinik wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: Livnat Peer lp...@redhat.com, Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org, Michael Kublin mkub...@redhat.com Sent: Sunday, July 22, 2012 7:41:00 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/22/2012 07:38 PM, Allon Mureinik wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: Itamar Heim ih...@redhat.com, Michael Kublin mkub...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org Sent: Sunday, July 22, 2012 9:50:47 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 21/07/12 15:15, Itamar Heim wrote: On 07/19/2012 03:34 PM, Ayal Baron wrote: - Original Message - On Jul 19, 2012, at 14:14 , Livnat Peer wrote: On 19/07/12 14:41, Juan Hernandez wrote: On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: On 07/19/2012 02:31 PM, Vojtech Szocs wrote: Don't we need that (the source part) to avoid Java 7 syntax in GWT code? That's a very good point. In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail. So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however. We could do something like this: - let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6) (note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code) What do you think? Vojtech +1 - I really like this idea! +1 from me as well. There are two calls to make when it comes to JDK7 (regardless of GWT - excuse me for taking this discussion some steps backwards) 1. Are we running with JRE 7? The answer is yes we agreed on that a few months ago. 2. Are we using code syntax which is incompatible with JDK6? I think the answer to the above should be no (at least for now - maybe until the next ovirt release?). +1 exactly. Why starting with jdk6 incompatible constructs unless there is a good (or at least any) reason for them… +1 +1 - there is merit keeping backward compatibility to allow comparing behavior while java 7 is still young. Since no one objected, we'll go with JDK6 syntax compatibility for Now. I'm a very small fan of enforcing policy by reviewers. Not that the community reviews aren't great - but people miss things. Here's my take on Maven's enforcer plugin to actually verify we aren't compiling with JDK 7: http://gerrit.ovirt.org/#/c/6523 we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side. I don't understand this suggestion. What you're saying is that you can compile with whatever JDK you want, but: - it won't compile with JDKs prior to 6, since we're using 6's features. - you aren't allowed to use JDK 7 features, and if you do, you'll get an email from jenkins that you broke something and must fix it. To me, this sounds a lot like enforcing JDK 6 compatibility. its preserving jdk 6 compatibility for a few more months, not enforcing to use jdk 6 compiler. Fair enough. /today/ if have way too many (i.e., 0) jenkins breaks, a lot of which could be avoided by not running
Re: [Engine-devel] java 1.6 compatibility no more?
- Original Message - From: Itamar Heim ih...@redhat.com To: Juan Hernandez jhern...@redhat.com Cc: Allon Mureinik amure...@redhat.com, engine-devel@ovirt.org Sent: Monday, July 23, 2012 2:44:02 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/23/2012 02:31 PM, Juan Hernandez wrote: Well, for me personally the price is actually zero, as I don't use the Eclipse maven support ;-) . But I know that many people hates when they try to import the projects and they get errors because of plugins that Eclipse doesn't understand. Let's see what they think. ovirt should load in eclipse without any error, and we are working on cleaning this up as it currently requires manual work to clean up the errors to work in eclipse (which i find less than friendly to new community members) Agreed. I didn't notice any problems in working in Eclipse (I use Juno) + Maven + this plugin, but if anyone did, I'd appreciate the feedback. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] java 1.6 compatibility no more?
- Original Message - From: Vojtech Szocs vsz...@redhat.com To: Juan Hernandez jhern...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 2:31:40 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more? Don't we need that (the source part) to avoid Java 7 syntax in GWT code? That's a very good point. In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). This may be nitpicking, but there is a difference: Java 6 allows the @Override annotation for implementing interfaces, while Java 5 restricts it to actual overrides. This is widely used throughout our code, at least in the backend side. For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail. So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however. We could do something like this: - let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6) (note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code) What do you think? Vojtech - Original Message - From: Juan Hernandez jhern...@redhat.com To: Vojtech Szocs vsz...@redhat.com Cc: Yair Zaslavsky yzasl...@redhat.com, engine-devel@ovirt.org Sent: Thursday, July 19, 2012 11:01:00 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/19/2012 10:09 AM, Vojtech Szocs wrote: As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes? I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well? If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance. Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build. Don't we need that (the source part) to avoid Java 7 syntax in GWT code? - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 7:59:45 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/18/2012 08:21 PM, Juan Hernandez wrote: On 07/18/2012 06:33 PM, Vojtech Szocs wrote: In fact, for both backend and frontend, Maven effective POM contains: artifactIdmaven-compiler-plugin/artifactId configuration source1.6/source target1.6/target /configuration Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?) These maven settings just tell the java compiler to accept Java 6 syntax only and to generate a Java 6 compatible .class file format, but they don't restrict the set of APIs that can be used. The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method. I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method). Vojtech As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes? - Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: engine-devel engine-devel@ovirt.org Cc: Vojtech Szocs vsz...@redhat.com Sent: Wednesday, July 18, 2012 5:43:34 PM Subject: java 1.6 compatibility no more? Hi, It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional? Laszlo ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 -
Re: [Engine-devel] java 1.6 compatibility no more?
- Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: Juan Hernandez jhern...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 3:04:17 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more? Hi, At the moment if you update the source and target settings of the compiler plugin to 1.7 in the root pom, the project will build fine, but some of the junit tests will fail. (some strange problem with bytecode manipulation see here http://code.google.com/p/powermock/issues/detail?id=355) The real solution for this is to stop using powermock, an effort we've been pursuing for the last couple of months. After merging a couple more patches that were already approved and just waiting for merge on the subject (http://gerrit.ovirt.org/#/c/6280/ http://gerrit.ovirt.org/#/c/6392/ - if one of the maintainers can lend a hand), we remain with two failures which both originate from the same place: org.ovirt.engine.api.restapi.resource.BackendResourceDebugDetailTest org.ovirt.engine.api.restapi.resource.BackendResourceInfoDetailTest Both of these failures are due to powermocking in AbstractBackendResourceLoggingTest. Basically, this test is used for testing that the logging in BaseBackendResource.detail(Throwable) method is done properly. Not sure how useful this is (perhaps someone more familiar with REST-API can shed some insight?), but if this is the only thing preventing us from moving to jdk-7... well.. Moving only the source does not work, moving only the target leaves the junit tests failing. So as you see I have rejected my own patch :-) http://gerrit.ovirt.org/6447/ Laszlo - Original Message - From: Juan Hernandez jhern...@redhat.com To: Vojtech Szocs vsz...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 1:41:26 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: On 07/19/2012 02:31 PM, Vojtech Szocs wrote: Don't we need that (the source part) to avoid Java 7 syntax in GWT code? That's a very good point. In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail. So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however. We could do something like this: - let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6) (note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code) What do you think? Vojtech +1 - I really like this idea! +1 from me as well. - Original Message - From: Juan Hernandez jhern...@redhat.com To: Vojtech Szocs vsz...@redhat.com Cc: Yair Zaslavsky yzasl...@redhat.com, engine-devel@ovirt.org Sent: Thursday, July 19, 2012 11:01:00 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/19/2012 10:09 AM, Vojtech Szocs wrote: As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes? I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well? If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance. Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build. Don't we need that (the source part) to avoid Java 7 syntax in GWT code? - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 7:59:45 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/18/2012 08:21 PM, Juan Hernandez wrote: On 07/18/2012 06:33 PM, Vojtech Szocs wrote: In fact, for both backend and frontend, Maven effective POM contains: artifactIdmaven-compiler-plugin/artifactId configuration source1.6/source target1.6/target /configuration Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's
Re: [Engine-devel] java 1.6 compatibility no more?
- Original Message - From: Ayal Baron aba...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org, Allon Mureinik amure...@redhat.com Sent: Sunday, July 22, 2012 8:34:32 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more? - Original Message - On 07/22/2012 07:38 PM, Allon Mureinik wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: Itamar Heim ih...@redhat.com, Michael Kublin mkub...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org Sent: Sunday, July 22, 2012 9:50:47 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 21/07/12 15:15, Itamar Heim wrote: On 07/19/2012 03:34 PM, Ayal Baron wrote: - Original Message - On Jul 19, 2012, at 14:14 , Livnat Peer wrote: On 19/07/12 14:41, Juan Hernandez wrote: On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: On 07/19/2012 02:31 PM, Vojtech Szocs wrote: Don't we need that (the source part) to avoid Java 7 syntax in GWT code? That's a very good point. In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail. So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however. We could do something like this: - let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6) (note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code) What do you think? Vojtech +1 - I really like this idea! +1 from me as well. There are two calls to make when it comes to JDK7 (regardless of GWT - excuse me for taking this discussion some steps backwards) 1. Are we running with JRE 7? The answer is yes we agreed on that a few months ago. 2. Are we using code syntax which is incompatible with JDK6? I think the answer to the above should be no (at least for now - maybe until the next ovirt release?). +1 exactly. Why starting with jdk6 incompatible constructs unless there is a good (or at least any) reason for them… +1 +1 - there is merit keeping backward compatibility to allow comparing behavior while java 7 is still young. Since no one objected, we'll go with JDK6 syntax compatibility for Now. I'm a very small fan of enforcing policy by reviewers. Not that the community reviews aren't great - but people miss things. Here's my take on Maven's enforcer plugin to actually verify we aren't compiling with JDK 7: http://gerrit.ovirt.org/#/c/6523 we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side. Instead of enforcing the compilation to be run with a specific jdk we can enforce that the code is java 6 compatible with: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.6/source target1.6/target /configuration /plugin No, this is not the issue we're discussing. The source and target configurations in the maven-compiler-plugin specify the language level compatibility (i.e., syntax) you're using. This setting only means you won't be able to use Java 7 new syntactic constructs like catching multiple exceptions with the pipe operator and shorthand generics. This has nothing to do with the JDK. The JDK is just a collection of jars, like any other jar, which just happen to contain some fundamental classes like Object, String and Long. Our case here is to force developers not use any methods/classes that aren't present in /JDK 6/. Just to prove the point - if you take a look at lines 367-368 of the master pom.xml, you'll notice we already have these settings, and have had them since oVirt's git repo was created. comments welcome. Kublin - can you please send a patch to remove the usage of Long.Compare in StorageDomainCommandBase Thanks, Livnat ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list
Re: [Engine-devel] java 1.6 compatibility no more?
- Original Message - From: Itamar Heim ih...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: Livnat Peer lp...@redhat.com, Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org, Michael Kublin mkub...@redhat.com Sent: Sunday, July 22, 2012 7:41:00 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/22/2012 07:38 PM, Allon Mureinik wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: Itamar Heim ih...@redhat.com, Michael Kublin mkub...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org Sent: Sunday, July 22, 2012 9:50:47 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 21/07/12 15:15, Itamar Heim wrote: On 07/19/2012 03:34 PM, Ayal Baron wrote: - Original Message - On Jul 19, 2012, at 14:14 , Livnat Peer wrote: On 19/07/12 14:41, Juan Hernandez wrote: On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: On 07/19/2012 02:31 PM, Vojtech Szocs wrote: Don't we need that (the source part) to avoid Java 7 syntax in GWT code? That's a very good point. In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail. So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however. We could do something like this: - let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6) (note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code) What do you think? Vojtech +1 - I really like this idea! +1 from me as well. There are two calls to make when it comes to JDK7 (regardless of GWT - excuse me for taking this discussion some steps backwards) 1. Are we running with JRE 7? The answer is yes we agreed on that a few months ago. 2. Are we using code syntax which is incompatible with JDK6? I think the answer to the above should be no (at least for now - maybe until the next ovirt release?). +1 exactly. Why starting with jdk6 incompatible constructs unless there is a good (or at least any) reason for them… +1 +1 - there is merit keeping backward compatibility to allow comparing behavior while java 7 is still young. Since no one objected, we'll go with JDK6 syntax compatibility for Now. I'm a very small fan of enforcing policy by reviewers. Not that the community reviews aren't great - but people miss things. Here's my take on Maven's enforcer plugin to actually verify we aren't compiling with JDK 7: http://gerrit.ovirt.org/#/c/6523 we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side. I don't understand this suggestion. What you're saying is that you can compile with whatever JDK you want, but: - it won't compile with JDKs prior to 6, since we're using 6's features. - you aren't allowed to use JDK 7 features, and if you do, you'll get an email from jenkins that you broke something and must fix it. To me, this sounds a lot like enforcing JDK 6 compatibility. /today/ if have way too many (i.e., 0) jenkins breaks, a lot of which could be avoided by not running with -DskipTetst or making sure to run with -Penable-dao-tests. I fear this suggestion will just add to this noise, and could easily be avoided. comments welcome. Kublin - can you please send a patch to remove the usage of Long.Compare in StorageDomainCommandBase Thanks, Livnat ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Forking unit tests
- Original Message - From: Allon Mureinik amure...@redhat.com To: Mike Kolesnik mkole...@redhat.com Sent: Thursday, June 14, 2012 12:12:54 PM Subject: Re: Forking unit tests - Original Message - From: Mike Kolesnik mkole...@redhat.com To: Allon Mureinik amure...@redhat.com Cc: Laszlo Hornyak lhorn...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Wednesday, June 13, 2012 1:28:36 PM Subject: Re: Forking unit tests Hi guys, If you're using settings.xml as published in Building the oVirt Engine page, you'd see we're forking for every test, in every subproject. This behaviour was introduced to handle memory leaks in PowerMock we use in some subprojects, but is redundant in others. Over the past month or so I've been working on removing PowerMock from as many places as possible (many thanks to mkolesni and lhornyak!), and we've got to the stage that forking is only needed in to subprojects - bll and resttypes. +1 - great job! 10x! Would it be possible to have this as a parameter (defaul true) that can be overridden, such as -Dengine.forkTests=false ? couldn't find a good way to do it forkMode doesn't seem to work when given a property as a value, sorry. :-( Take a look at http://gerrit.ovirt.org/#/c/5653/1. Once it is merged, you could user -Dengine.powermock.fork=one to stop forking. The forking was defined explicitly in those two projects, so if you want to speed up your tests, just take the latest version of settings.xml from http://ovirt.org/wiki/Building_oVirt_engine#Maven_personal_settings. -Allon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Developer's All In One
Cross-posting to engine-devel - Forwarded Message - From: Yeela Kaplan ykap...@redhat.com To: vdsm-de...@lists.fedorahosted.org, engine-de...@lists.fedorahosted.org Cc: Ayal Baron aba...@redhat.com Sent: Monday, June 18, 2012 2:58:55 PM Subject: Developer's All In One Enclosed is the link to a wiki containing a detailed explanation for installing a developer's All-In-One environment: http://www.ovirt.org/wiki/Developers_All_In_One Regards, Yeela ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Forking unit tests
- Original Message - From: Roy Golan rgo...@redhat.com To: engine-devel@ovirt.org Sent: Wednesday, June 13, 2012 4:14:06 PM Subject: Re: [Engine-devel] Forking unit tests On 06/13/2012 03:41 PM, Laszlo Hornyak wrote: We can just move the surefire config to a higher level in the pom hierarchy, but that makes the tests slower globaly. It is more work, but we could help Allon to rewrite the Powermock tests :-) And then the surefire settings could be removed and the tests will run quick again. great job. I think that any further effort we want to put in refactoring the tests must be in abstracting the code *first* i.e creating facade + interfaces + getters instead of static calling classes (Backend, Config, DbFacade ...) . that way we can avoid a lot of mocking code (mkublin we can remove a lot of code here!) +gazilion. - Original Message - From: Yair Zaslavskyyzasl...@redhat.com To: Mike Kolesnikmkole...@redhat.com Cc: engine-develengine-devel@ovirt.org Sent: Wednesday, June 13, 2012 1:44:39 PM Subject: Re: [Engine-devel] Forking unit tests On 06/13/2012 01:28 PM, Mike Kolesnik wrote: Hi guys, If you're using settings.xml as published in Building the oVirt Engine page, you'd see we're forking for every test, in every subproject. This behaviour was introduced to handle memory leaks in PowerMock we use in some subprojects, but is redundant in others. Over the past month or so I've been working on removing PowerMock from as many places as possible (many thanks to mkolesni and lhornyak!), and we've got to the stage that forking is only needed in to subprojects - bll and resttypes. +1 - great job! +1 Would it be possible to have this as a parameter (defaul true) that can be overridden, such as -Dengine.forkTests=false ?+ +1 - good idea. The forking was defined explicitly in those two projects, so if you want to speed up your tests, just take the latest version of settings.xml from http://ovirt.org/wiki/Building_oVirt_engine#Maven_personal_settings. -Allon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] oVirt UI: Legacy UserPortal removed
awesome! - Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: Vojtech Szocs vsz...@redhat.com, engine-devel@ovirt.org Sent: Thursday, June 14, 2012 2:29:40 PM Subject: Re: [Engine-devel] oVirt UI: Legacy UserPortal removed Hi, A visualization of how that counts (from sonar) https://twitter.com/kozka/status/213229060103483392/photo/1 Laszlo - Original Message - From: Vojtech Szocs vsz...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, June 14, 2012 12:55:18 PM Subject: [Engine-devel] oVirt UI: Legacy UserPortal removed Hi everyone, please note that the original (SmartGWT-based) UserPortal application has been removed from oVirt repository, as part of patch [http://gerrit.ovirt.org/5317]. This has no impact on the current UserPortal application, which is part of the standard oVirt Maven build. Please let me know if you have any questions. Thanks, Vojtech ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Testing queries
Hi guys, following some questions from last week regarding writing unit-tests for query objects, I whipped up this quick wiki page: http://ovirt.org/wiki/Testing_Queries Enjoy, Allon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] git-review error.
Hi Sharad, I'm not too big on git-review, but AFAIK -t is used to supply a topic (see https://github.com/openstack-ci/git-review#readme). can you try with an explicit notation refs/for/master/nullpointer ? -Allon - Original Message - From: snmis...@linux.vnet.ibm.com To: engine-devel@ovirt.org Sent: Monday, May 14, 2012 9:07:38 PM Subject: [Engine-devel] git-review error. Hi, I am trying to push a patch to gerrit for review. $ ./git-review -t nullpointer remote: Resolving deltas: 0% (0/6) To ssh://snmis...@gerrit.ovirt.org:29418/ovirt-engine.git ! [remote rejected] HEAD - refs/publish/master/nullpointer (prohibited by Gerrit) error: failed to push some refs to 'ssh://snmis...@gerrit.ovirt.org:29418/ovirt-engine.git' I can ssh to gerrit.ovirt.org without password, so that seems to be setup correctly. git-review version is 1.17. I am on 'nullpointer' branch. Thanks in advance for your help. Regards Sharad Mishra ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] The easy way to mock Config in your unit tests
Here's the outcome of the thread below: http://ovirt.org/wiki/MockConfigRule Enjoy! Many thanks to the patches' reviewers. - Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Monday, May 7, 2012 2:23:10 PM Subject: Re: [Engine-devel] The correct way to create test dependencies between +1 I like the idea, I think this would really improve our unit tests. - Original Message - From: Allon Mureinik amure...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Sunday, May 6, 2012 2:46:03 PM Subject: [Engine-devel] The correct way to create test dependencies between Hi guys, I've recently come up with (what I believe is) an elegant way to mock the Config object using JUnit @Rules and Mockito (The gritty details can be found at http://gerrit.ovirt.org/4155). This presented me with another issue: On the one hand, the code depends on junit and mockito jars, which are not available in the main scope, only in the test scope. On the other hand, in vanilla Maven there is no dependency between tests of different projects, so placing this class in util's test would make it inaccessible to bll tests. The solution Maven suggests for these kind of issues is creating a test jar (http://maven.apache.org/guides/mini/guide-attached-tests.html): In addition to the regular jar the module produces, you'll get another -test jar, which other modules can depend on using the typetest-jar/type, which could of course be put in scopetest/scope. Before pushing forward with this approach, I'd like to know if anyone has a principle objection to it. Thanks, Allon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] revievers needed
I'd be happy to review them, but someone else will have to +2 them. - Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, March 15, 2012 12:50:31 PM Subject: [Engine-devel] revievers needed Hi, I have a big pile of patches waiting for reviewers, some of them are very old. If you have some spare-time, please take any: http://gerrit.ovirt.org/#dashboard,127 Thank you, Laszlo ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
