- Devel - oVirt List Archives

[Engine-devel] oVirt 3.2 test-day
by Moran Goldboim 31 Jan '13

31 Jan '13

we were supposed to have test day tomorrow, but we decided to push it to Thursday (Jan 31) to have ovirt-node and proper infra for test day (Mike should announce it's officially soon). I have refreshed http://www.ovirt.org/Testing/OvirtTestDay, but there is action from your part as well: -go over the scenarios (regressions), see if those relevant, add more if needed remove if not. -add basic tests for your new 3.2 features. -assign a contributor to be actively present on helping users on his area -make commitment and participate the test day I would like to review this document by Wednesday on users meeting, please make sure your part is updated by than. Thanks, Moran.

7 8

[Engine-devel] when import ovirt-engine to eclipse, it cann't find the .project file.
by 陈超 31 Jan '13

31 Jan '13

Hi all, I am trying to set up an eclipse development environment for ovirt-engine and am running into a stubborn problem with missing classes. I have followed the directions for importing the Maven projects as written here: http://ovirt.org/wiki/Building_Ovirt_Engine/IDE,but there is no '.project' file,when I git clone from the gerrit.I should have a complete ovirt-engine source repository (I cloned the ovirt-engine git repo). Has anyone seen this problem before? Can you offer any suggestions to help me resolve it? Thanks! chenchao. thanks

3 2

[Engine-devel] jpa annotations
by Laszlo Hornyak 31 Jan '13

31 Jan '13

Hi, We have JPA annotations on the backend entity beans, but they have never been actually used as far as I know and now that I looked into VmTemplate for example we do not even have a vm_template table anymore, while VmTemplate still refers to it. Any plans with the JPA? Laszlo

6 8

[Engine-devel] Time to move to 3.3.0-SNAPSHOT?
by Juan Hernandez 30 Jan '13

30 Jan '13

Once 3.2.0 is released I think we should move to 3.3.0-SNAPSHOT in the master branch: http://gerrit.ovirt.org/11143 -- 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.

6 26

[Engine-devel] [engine-devel] frontend builders proposal
by Tomas Jelinek 30 Jan '13

30 Jan '13

Hi All, as many of you may know, the way how the frontend and backend models are built on frontend (uicommonweb project) is not really ideal. Currently this logic is copy pasted over and over again to different places where it is needed with minor changes to fulfill the specific requirements. It is not only aesthetically problematic, but I recall tons of bugs caused by introducing a new field and forgetting to add it to every place it is used in GUI. Now, as there will be big changes in the VM/Template models (http://www.ovirt.org/Features/Instance_Types) so the way how the VM, Template, Pool and also the newly created Instance Types models are being built has to be touched anyhow, it is a great opportunity to rethink the way how we do it. I have created a simple infrastructure (http://gerrit.ovirt.org/#/c/10874/) which could be used for it, and a PoC patch which uses this infrastructure (http://gerrit.ovirt.org/#/c/11354/) Please note that the PoC is not really impressive in means of removing duplications, I wanted to start with the simplest possibility. The principles behind the infrastructure: - have small, well named, easy to understand and reuse builders - this builders can be chained together or embedded to each other to build the full resulting object (composite pattern) - this builders can be asynchronous, and the next builder in the chain has to be executed only when the current is completely done The structure: - the base is an interface called Builder which has a method build(source, destination, rest) - the builder implementing this interface + will get the source and destination objects + copies whatever he wants from source to destination + when done, executes build on the first element of the rest + this may sound awkward, but this is the way how the async calls can be "linearized" in a general way, not embedding anonymous class into anonymous class into anonymous class... as we do it today. + for synchronous builders, there is a BaseSyncBuilder which takes care of this boilerplate calling of next and exposes a simple method build(S source, D destination) + to simplify the creating and running the chain of builders, there is a BuilderExecutor class (can be created as sync or async) So, a simple example - even more simple than the PoC patch :) //create the first builder class FirstLetterBuilder extends BaseSyncBuilder<String, StringBuilder> { @Override protected void build(String source, StringBuilder destination) { // copy the first letter to the destination destination.append(source.charAt(0)); } } //create the second builder class SecondLetterBuilder extends BaseSyncBuilder<String, StringBuilder> { @Override protected void build(String source, StringBuilder destination) { // copy the second letter to the destination destination.append(source.charAt(1)); } } // usage ... // create the destination object StringBuilder res = new StringBuilder(); // configure the executor with the two builders BuilderExecutor<String, StringBuilder> executor = new BuilderExecutor<String, StringBuilder>( new FirstLetterBuilder(), new SecondLetterBuilder() ); // execute the builder chain ("ab" is the source, res the destination) executor.build("ab", res); // use the result ... That's it. And the nice part is, that this FirstLetterBuilder and SecondLetterBuilder can be reused anywhere or combined with any other builders. Any comments on this will be more than welcome! Thank you, Tomas

4 6

[Engine-devel] ovirt-engine-sdk-java 1.0.0.3-1 released
by Michael Pasternak 30 Jan '13

30 Jan '13

- added persistent authentication support - added support for the methods overloads based on url/headers params - added delete methods overloads with body as parameters holder - to host added [display.address] property for overriding display address - user can specify own ticket now in vm.ticket() via [action.ticket.value] More details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 0

Re: [Engine-devel] [engine-devel] frontend builders proposal
by Tomas Jelinek 30 Jan '13

30 Jan '13

Hi Tal, > I was wondering, for entity such as VM, isn't it better to make a > builder for the entity as a whole? Unless you know of a specific parts > that are used in smaller units? well, when you create a new VM or a Template, in both cases you need to build the VM entity from UnitVmModel. But, not all the fields which are taken from the UnitVmModel in case of creating the new VM are used also for new Template. So, in this case both can use CommonUnitToVmBuilder and QuotaUnitToVmBuilder, but the creating of the VM uses also others (e.g. UsbPolicyUntiToVmBuilder etc) The situation will be even more complex when the Instance Types and the Images will be introduced which all will be basically VM and UnitVmModel subsets. So, they will be able to use some of the common builders but not all and will have some custom. Tomas ----- Original Message ----- From: "Tal Nisan" <tnisan(a)redhat.com> To: "Tomas Jelinek" <tjelinek(a)redhat.com> Sent: Monday, January 28, 2013 5:44:31 PM Subject: Re: [Engine-devel] [engine-devel] frontend builders proposal Hi Tomas, I was wondering, for entity such as VM, isn't it better to make a builder for the entity as a whole? Unless you know of a specific parts that are used in smaller units? Tal. On 01/25/2013 11:55 AM, Tomas Jelinek wrote: > Hi All, > > as many of you may know, the way how the frontend and backend models are built on frontend (uicommonweb project) is not really ideal. Currently this logic is copy pasted over and over again to different places where it is needed with minor changes to fulfill the specific requirements. It is not only aesthetically problematic, but I recall tons of bugs caused by introducing a new field and forgetting to add it to every place it is used in GUI. > > Now, as there will be big changes in the VM/Template models (http://www.ovirt.org/Features/Instance_Types) so the way how the VM, Template, Pool and also the newly created Instance Types models are being built has to be touched anyhow, it is a great opportunity to rethink the way how we do it. > > I have created a simple infrastructure (http://gerrit.ovirt.org/#/c/10874/) which could be used for it, and a PoC patch which uses this infrastructure (http://gerrit.ovirt.org/#/c/11354/) Please note that the PoC is not really impressive in means of removing duplications, I wanted to start with the simplest possibility. > > The principles behind the infrastructure: > - have small, well named, easy to understand and reuse builders > - this builders can be chained together or embedded to each other to build the full resulting object (composite pattern) > - this builders can be asynchronous, and the next builder in the chain has to be executed only when the current is completely done > > The structure: > - the base is an interface called Builder which has a method build(source, destination, rest) > - the builder implementing this interface > + will get the source and destination objects > + copies whatever he wants from source to destination > + when done, executes build on the first element of the rest > + this may sound awkward, but this is the way how the async calls can be "linearized" in a general way, not embedding anonymous class into anonymous > class into anonymous class... as we do it today. > + for synchronous builders, there is a BaseSyncBuilder which takes care of this boilerplate calling of next and exposes a simple method > build(S source, D destination) > + to simplify the creating and running the chain of builders, there is a BuilderExecutor class (can be created as sync or async) > > So, a simple example - even more simple than the PoC patch :) > > //create the first builder > class FirstLetterBuilder extends BaseSyncBuilder<String, StringBuilder> { > @Override > protected void build(String source, StringBuilder destination) { > // copy the first letter to the destination > destination.append(source.charAt(0)); > } > } > > //create the second builder > class SecondLetterBuilder extends BaseSyncBuilder<String, StringBuilder> { > @Override > protected void build(String source, StringBuilder destination) { > // copy the second letter to the destination > destination.append(source.charAt(1)); > } > } > > // usage > ... > // create the destination object > StringBuilder res = new StringBuilder(); > > // configure the executor with the two builders > BuilderExecutor<String, StringBuilder> executor = new BuilderExecutor<String, StringBuilder>( > new FirstLetterBuilder(), > new SecondLetterBuilder() > ); > > // execute the builder chain ("ab" is the source, res the destination) > executor.build("ab", res); > > // use the result > ... > > That's it. And the nice part is, that this FirstLetterBuilder and SecondLetterBuilder can be reused anywhere or combined with any other builders. > > Any comments on this will be more than welcome! > > Thank you, > Tomas > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel

1 0

[Engine-devel] 3.2 features for release notes
by Cheryn Tan 30 Jan '13

30 Jan '13

Hi all, I'm preparing the oVirt 3.2 release notes, starting with the features listed here: http://www.ovirt.org/OVirt_3.2_release-management#Features Can you please go through the list, and reply to this thread if: a) There are features being released for 3.2 which should be documented, but are not on the list; or b) Some of the planned features on this list are not being released for 3.2; or c) Some of the features on this list are being released for 3.2, but should not be documented. For features which aren't on the wiki, please send a short description or Bugzilla numbers of each feature. Please reply no later than Jan 28. Thank you very much for your help! Cheryn

13 15

[Engine-devel] unit tests failing
by Alon Bar-Lev 29 Jan '13

29 Jan '13

Don't know what change exactly caused this: Tests in error: canDoActionInvalidVmStatus(org.ovirt.engine.core.bll.MoveDisksCommandTest) moveDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest) liveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest) liveMigrateDiskBasedOnTemplate(org.ovirt.engine.core.bll.MoveDisksCommandTest) moveDiskAndLiveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest)

5 7

[Engine-devel] Improving of exist memory lock infrastructure in ovirt-engine
by Michael Kublin 29 Jan '13

29 Jan '13

The following link http://www.ovirt.org/Features/DetailedLockMechanism contains description and design of in memory lock infrastructure. The design is describing already existing infrastructure with additional changes that should be done in order to improve it. The idea is to allow using of in memory locks with commands that can create asynchronous tasks. Regards Michael

2 1