- Devel - oVirt List Archives

[Engine-devel] oVirt database upgrade procedure moved
by Eli Mesika 20 Apr '12

20 Apr '12

New location http://www.ovirt.org/wiki/OVirt-database-upgrade-procedure

1 0

[Engine-devel] [Jenkins] unit test fails
by Eyal Edri 19 Apr '12

19 Apr '12

fyi, 1 unit test fails after these commits: (lots of commits, since the Jenkins server was stuck during that time). http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/626/ the failed test: org.ovirt.engine.core.utils.serialization.json.JsonObjectSerializerTest.testSerialize Eyal Edri oVirt Infra Team.

2 1

Re: [Engine-devel] Floating Disks implementation in REST-API
by Ori Liel 19 Apr '12

19 Apr '12

I'd like us to move forward with this. The option of using 'attach' action does not exist, because, as Eoghan observed, we would be executing an action on an entity which doesn't exist in the collection: (.../api/vms/{vm:id}/disks/???-no entity-???/attach) There are two options left on the table; let's see if we can agree on one of them: 1) POST/api/vms/{vm:id}/disks <disk id="{disk:id}"/> => attach disk DELETE .../api/vms/{vm:id}/disks/{disk:id} <disk><detach>true</detach><disk> => detach disk Pros: symmetrical Cons: risky (if user wants to detach but forgot to give parameter, disk will be deleted). 2) POST/api/vms/{vm:id}/disks <disk id="{disk:id}"/> => attach disk DELETE .../api/vms/{vm:id}/disks/{disk:id}/detach => detach disk Pros: not dangerous Cons: asymmetrical, attach done like add, but detach done using action. No solution is perfect but we need to decide. Thanks, Ori.

6 20

[Engine-devel] Jar versions in ovirt-engine
by Ofer Schreiber 19 Apr '12

19 Apr '12

Ever wondered why the version of oVirt's first release is 3.0.0_0001? The answer is simple - We use ovirt-engine jar's version as our "main" release version. Personally, I think the current versioning scheme is ugly. Actually, I can't name even one open-source project using "_" in it's version. What can we do about it? We have couple of options: 1. Leave the engine alone, and use a separate versioning scheme (e.g - use just 3.1.0 as the main version for next release) 2. Remove "_" from engine jars 3. Do nothing. I'd like to hear your thoughts, as well as the reasons to use such an unusual versioning scheme. --- Ofer Schreiber oVirt Release Manager

4 11

[Engine-devel] [Jenkins] ovirt-engine fails due to last commit
by Eyal Edri 19 Apr '12

19 Apr '12

commit b9a6f23be188e2bf4d56f8b548db1b2536372385 - core: Add methods missing from PGHack (detail / gitweb) Compilation Error: Waiting for Jenkins to finish collecting data mavenExecutionResult exceptions not empty message : Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project dal: Compilation failure /home/jenkins/workspace/ovirt_engine/backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dal/dbbroker/PGHack.java:[68,19] cannot find symbol symbol : method getParentLogger() location: interface javax.sql.DataSource cause : Compilation failure /home/jenkins/workspace/ovirt_engine/backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dal/dbbroker/PGHack.java:[68,19] cannot find symbol symbol : method getParentLogger() location: interface javax.sql.DataSource Stack trace : org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project dal: Compilation failure /home/jenkins/workspace/ovirt_engine/backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dal/dbbroker/PGHack.java:[68,19] cannot find symbol symbol : method getParentLogger() location: interface javax.sql.DataSource at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79) 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:616) at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158) at hudson.maven.Maven3Builder.call(Maven3Builder.java:122) at hudson.maven.Maven3Builder.call(Maven3Builder.java:74) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure /home/jenkins/workspace/ovirt_engine/backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dal/dbbroker/PGHack.java:[68,19] cannot find symbol symbol : method getParentLogger() location: interface javax.sql.DataSource at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:656) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 27 more

4 4

[Engine-devel] Maven 3 here we come!
by Doron Fediuck 18 Apr '12

18 Apr '12

Hi guys, We're trying to be as updated as possible in oVirt development. In order to catch up with recent changes in major distro's, we'd like to move to Maven 3. Current oVirt engine code actually can be built with Maven 3 now, but we still need to handle some minor issues. Also we need to update our wiki's accordingly. To make this move coordinated, and give everyone some time to play with Maven 3, I suggest we do it in 2 weeks from now, and move on April 29. Basically the code should remain the same, other than minor changes we may need to do. If you have substantials considerations against maven3, please share. -- /d "Who's General Failure and why's he reading my disk?"

2 2

[Engine-devel] ovirt-engine deployment method
by Ofer Schreiber 18 Apr '12

18 Apr '12

As decided earlier, oVirt next release (3.1) is targeted for Fedora 17. Since the engine uses JBoss, we have two deployment options: 1. Continue working with ovirt-engine-jbossas package PROS: Single rpm. known upgrade method. CONS: Maintaining un-natural zip based rpm. No official support. Can't be pushed into Fedora. 2. Move to JBoss F17 official packages: PROS: Fully supported F17 rpms (including bug fixes, security fixes, etc). "The right thing to do". CONS: Upgrade from first release (relaying on old jboss) will be almost impossible, Some open issues (will it work just as as normal service? or will we need to code a new one?), Might cause a delay to Feature Freeze. Thought? Comments? Share them with us! --- Ofer Schreiber oVirt Release Manager

5 10

[Engine-devel] java enum syntax trick
by Laszlo Hornyak 18 Apr '12

18 Apr '12

Hi, In java enums, you can leave a coma before the semicolon closing the names in the enum. e.g. enum Foo { bar, baz, // <!-- last, still with a coma ; //and there is no more } I don't know if this fits in the code formating requirements, but maybe it could help us to waste less time on merging because you did not have to change the last line to add some more. Laszlo

2 1

[Engine-devel] Postgres DB Upgrade Procedure wiki
by Eli Mesika 17 Apr '12

17 Apr '12

Hi guys This is an updated version of our Postgres DB Upgrade Procedure. Most of it is not new and main changes are in the new "Configuration changes" section Please review and comment, we need this applied upstream ASAP http://www.ovirt.org/wiki/Postgres-database-upgrade-procedure

1 0

[Engine-devel] Query regarding ValidationUtils#validateInputs
by Shireesh Anjal 17 Apr '12

17 Apr '12

This is a multi-part message in MIME format. --------------060906010904020105000601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, This is regarding the following validation method we have in ValidationUtils: /public static <T extends VdcActionParametersBase> ArrayList<String> validateInputs(List<Class<?>> validationGroupList, T parameters);/ I there any particular reason for supporting the validations only on objects of classes derived from VdcActionParametersBase? I guess this was done because this method is primarily intended to validate the action parameters passed to a BLL action, using the validation annotations on the parameter class. However I think this method can be useful for general use as well. e.g. I cannot add a "@Valid" annotation on a "list" or a "map" in a parameter class. So I need to iterate over the list/map, and validate each element inside the loop. The validation inside the loop can also utilize the above method if the restriction "extends VdcActionParametersBase" is removed. This will allow me to do the following in the canDoAction method: protected boolean canDoAction() { ... for(GlusterBrickEntity brick : getParameters().getGlusterVolume().getBricks()) { List<String> errors = ValidationUtils.validateInputs(getValidationGroups(), brick); if(errors != null) { for(String error : errors) { addCanDoActionMessage(error); } } } ... } Regards, Shireesh --------------060906010904020105000601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi, This is regarding the following validation method we have in ValidationUtils: public static <T extends VdcActionParametersBase> ArrayList<String> validateInputs(List<Class<?>> validationGroupList, T parameters); I there any particular reason for supporting the validations only on objects of classes derived from VdcActionParametersBase? I guess this was done because this method is primarily intended to validate the action parameters passed to a BLL action, using the validation annotations on the parameter class. However I think this method can be useful for general use as well. e.g. I cannot add a "@Valid" annotation on a "list" or a "map" in a parameter class. So I need to iterate over the list/map, and validate each element inside the loop. The validation inside the loop can also utilize the above method if the restriction "extends VdcActionParametersBase" is removed. This will allow me to do the following in the canDoAction method: protected boolean canDoAction() { ...     for(GlusterBrickEntity brick : getParameters().getGlusterVolume().getBricks()) {         List<String> errors = ValidationUtils.validateInputs(getValidationGroups(), brick);         if(errors != null) {             for(String error : errors) {                 addCanDoActionMessage(error);             }         }     } ... } Regards, Shireesh </body> </html> --------------060906010904020105000601--

3 3