- Devel - oVirt List Archives

[Engine-devel] [Bug] Small Typo in api.xsd
by Sven Kieske 10 Dec '13

10 Dec '13

Hi, I just was reading through the new cloud-init api integration and found a small typo in: backend/manager/modules/restapi/interface/definition/src/main/resources/api.xsd Line 606: It is: " " but should be " ", I guess. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

2 2

[Engine-devel] make is failing in ovirt-engine master
by Kanagaraj 09 Dec '13

09 Dec '13

Hi, make clean install-dev PREFIX="$HOME/ovirt-engine" is failing with following error on master branch. if [ "1" != 0 ]; then \ build/python-check.sh; \ fi packaging/setup/ovirt_engine_setup/database.py:365:80: E501 line too long (82 > 79 characters) make[1]: *** [python-validation] Error 1 make[1]: Leaving directory `/home/kanagaraj/workspace/ovirt-engine' make: *** [all-dev] Error 2 Can someone please fix this? Thanks, Kanagaraj

3 2

[Engine-devel] master is broken by Common#VdcActionUtilsTest ??
by Michael Pasternak 09 Dec '13

09 Dec '13

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile (default-testCompile) on project common: Compilation failure: Compilation failure: [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[13,42] error: package org.ovirt.engine.core.common.action does not exist [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[14,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[15,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[16,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[17,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[18,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[19,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[20,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[21,52] error: cannot find symbol ... org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile (default-testCompile) on project common: Compilation failure 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.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) 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:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:656) at org.apache.maven.plugin.TestCompilerMojo.execute(TestCompilerMojo.java:161) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more -- Michael Pasternak RedHat, ENG-Virtualization R&D

2 2

[Engine-devel] Fwd: [Users] oVirt Cloud-Init integration REST-API
by Sven Kieske 09 Dec '13

09 Dec '13

Hi, I think this may be the more appropriate list to discuss this issue? I fear this isn't integrated yet and can't be integrated in 3.3.1 or 3.3.2? -------- Original-Nachricht -------- Betreff: [Users] oVirt Cloud-Init integration REST-API Datum: Fri, 6 Dec 2013 10:25:42 +0000 Von: Sven Kieske <S.Kieske(a)mittwald.de> An: gpadgett(a)redhat.com <gpadgett(a)redhat.com>, users(a)ovirt.org <users(a)ovirt.org> Hi, we want to utilize Cloud-Init via REST-API, like mentioned on the feature page in the wiki: http://www.ovirt.org/Features/Cloud-Init_Integration but looking at api?rsdl I do not find any clue if this is implemented already in 3.3.1? if yes, how to call this function? if no, can we hack something in the db to activate it or at least use the function to automatic build the cd-roms which get passed to the vms? I really need this feature. Thanks for your help. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

4 8

[Engine-devel] restapi: Permissions in Capabilities (#859225)
by Ori Liel 09 Dec '13

09 Dec '13

When listing the application's capabilities we currently show 'permissions' both for each version, and outside versions altogether: GET .../api/capabilities <capabilities> <permits></permits> <version major="3" minor="1" href="/api/capabilities/332e3133-2e31-332e-3133-2e31332e3133" id="332e3133-2e31-332e-3133-2e31332e3133"> <permits>...</permits> </version> <version major="3" minor="0" href="/api/capabilities/332e3033-2e30-332e-3033-2e30332e3033" id="332e3033-2e30-332e-3033-2e30332e3033"> <permits>...</permits> </version> </capabilities> 1) Permissions should only exist within a version; their current existence outside 'version' is for backwards compatibility only. We assume that no one (except perhaps Automation) uses these non-version-specific permissions these days, and we'd like to remove them. 2) Regarding permissions within a version - Oded brought up that some permissions which are only relevant for 3.1 are listed also under 3.0 (for example, quota related permissions). In order for the API layer to be able to group permissions by version, permission<-->version metadata must exist somewhere. The permissions enum in the engine seems a natural place to put it, as Michael commented. Setting out to do this, I realized that which-permission-belongs-to-which-version is knowledge that I don't have, and don't really know how to get efficiently, and I sort of got stuck because of this. Ideas regarding this issue? Thanks, Ori.

1 0

Re: [Engine-devel] Jenkins JAVA_HOME
by Itamar Heim 06 Dec '13

06 Dec '13

On 12/05/2013 09:55 PM, Gustavo Frederico Temple Pedrosa wrote: > Hello all, > > I have two changes that the build failed with "Error: JAVA_HOME is not > defined correctly." > > Anyone knows how I fix this? more details/link?

3 2

[Engine-devel] Using config values
by Kanagaraj 04 Dec '13

04 Dec '13

This is a multi-part message in MIME format. --------------050008020702070900040001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi All, The are some issues arising in configurations whenever we move up on the versions(3.3 => 3.4), because of the way we store and interpret them. Whenever there is a new cluster level, you will need to add a new entry for all(most) of the configuration. Mostly a copy paste if you see from 3.2 to 3.3, except some CPU/PM type related configurations. Better option would be to have the defaul config value in ConfigValues.java and the overrides will go to config.sql. In this approach you don't need a new entries to config.sql when there is a new cluster level. Lets take an exmaple, "SupportForceCreateVG" - This is supported from 3.1 onwards, If you look at config.sql, you will see following entries select fn_db_add_config_value('SupportForceCreateVG','false','3.0'); select fn_db_add_config_value('SupportForceCreateVG','true','3.1'); select fn_db_add_config_value('SupportForceCreateVG','true','3.2'); select fn_db_add_config_value('SupportForceCreateVG','true','3.3'); And in ConfigValues.java @TypeConverterAttribute(Boolean.class) @DefaultValueAttribute("false") SupportForceCreateVG, Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which i feel is redundant. Instead we can make @TypeConverterAttribute(Boolean.class) @DefaultValueAttribute("true") SupportForceCreateVG, and have only the following in config.sql select fn_db_add_config_value('SupportForceCreateVG','false','3.0'); if a particular value(for a specific cluster level) is not found in Config.sql, the fallback is to use the value available in ConfigValues.java. Please share your thoughts on this. Thanks, Kanagaraj --------------050008020702070900040001 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 All,<br> <br> The are some issues arising in configurations whenever we move up on the versions(3.3 => 3.4), because of the way we store and interpret them.<br> <br> Whenever there is a new cluster level, you will need to add a new entry for all(most) of the configuration. Mostly a copy paste if you see from 3.2 to 3.3, except some CPU/PM type related configurations.<br> Better option would be to have the defaul config value in ConfigValues.java and the overrides will go to config.sql. In this approach you don't need a new entries to config.sql when there is a new cluster level.<br> <br> Lets take an exmaple, "SupportForceCreateVG" - This is supported from 3.1 onwards,<br> <br> If you look at config.sql, you will see following entries <br> select fn_db_add_config_value('SupportForceCreateVG','false','3.0'); <br> select fn_db_add_config_value('SupportForceCreateVG','true','3.1'); <br> select fn_db_add_config_value('SupportForceCreateVG','true','3.2'); <br> select fn_db_add_config_value('SupportForceCreateVG','true','3.3');<br> <br> And in ConfigValues.java<br> <br>     @TypeConverterAttribute(Boolean.class)<br>     @DefaultValueAttribute("false")<br>     SupportForceCreateVG,<br> <br> Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which i feel is redundant.<br> <br> Instead we can make <br> <br>     @TypeConverterAttribute(Boolean.class)<br>     @DefaultValueAttribute("true")<br>     SupportForceCreateVG,<br> <br> and have only the following in config.sql<br> select fn_db_add_config_value('SupportForceCreateVG','false','3.0');<br> <br> if a particular value(for a specific cluster level) is not found in Config.sql, the fallback is to use the value available in ConfigValues.java.<br> <br> Please share your thoughts on this.<br> <br> Thanks,<br> Kanagaraj<br> <br> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </body> </html> --------------050008020702070900040001--

8 13

[Engine-devel] Adding users and assigning roles in Ovirt
by Ramesh 03 Dec '13

03 Dec '13

Hi All, We have 'Add' action under 'Users' main tab to add users in Ovirt . It looks slightly different from the "Add user" option of the Configure option. Actually, this one is missing the "Role to Assign" option. I think without assigning any role, adding a user is not meaningful and it didn't complete the flow. Currently to assign any role to the user, either we have to use 'Configure' option ( to add system permission) or we have to go to the specific entity and add permission for that entity. It will be nice if we can assign roles( system level permissions) while adding users in 'Users' tab itself. It will be a clear user flow where one can add user and assign role in the same place. I have attached both the screen shots. please share your thoughts. Regards, Ramesh

6 7

[Engine-devel] oVirt 3.3.2 Beta now available
by Sandro Bonazzola 03 Dec '13

03 Dec '13

The oVirt team is pleased to announce that the 3.3.2 Release is now available in beta. Release notes and information on the changes for this update are still being worked on and will be available soon on the wiki[1]. A new oVirt Node build will be available soon as well. You're welcome to join us testing [2] this beta release. [1] http://www.ovirt.org/OVirt_3.3.2_release_notes [2] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[Engine-devel] Remove Comment column in main tabs
by Mike Kolesnik 02 Dec '13

02 Dec '13

------=_Part_40758794_854245147.1385448274314 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, When the comment RFE was added (in 3.3), there was also a column added to many main tabs. I would like to propose to get rid of the column (which can only house one icon or no icon), and instead if there's a comment on an entity just display the icon with the tooltip adjacent to the name. In this case the icon should probably be scaled down a bit since its huge. I think this would be a good alternative and save us some valued screen real estate. Thoughts, opinions? Regards, Mike ------=_Part_40758794_854245147.1385448274314 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div>Hi,<br></div><div><br></div><div>When the comment RFE was added (in 3.3), there was also a column added to many main tabs.<br></div><div><br></div><div>I would like to propose to get rid of the column (which can only house one icon or no icon),</div><div>and instead if there's a comment on an entity just display the icon with the tooltip adjacent to the name.<br></div><div><br></div><div>In this case the icon should probably be scaled down a bit since its huge.<br></div><div><br></div><div>I think this would be a good alternative and save us some valued screen real estate.<br></div><div><br></div><div>Thoughts, opinions?<br></div><div><br></div><div><span name="x"></span>Regards,<br>Mike<span name="x"></span><br></div><div><br></div></div></body></html> ------=_Part_40758794_854245147.1385448274314--

5 16