- Devel - oVirt List Archives

[Engine-devel] Starting a new translation
by Alex Ont 17 Apr '13

17 Apr '13

Hi, Trying to translate the userportal ... How should one obtain the English properties file to jumpstart the translation? e.g. There are ApplicationConstants_xxx.properties for already translated locales, but there is no English version. Thanks, Alex

2 1

[Engine-devel] upgrade failing with latest master
by Dead Horse 16 Apr '13

16 Apr '13

logs attached First attempt: 2013-04-10 13:57:32::ERROR::common_utils::355::root:: YUM: FAIL: Error in PREUN scriptlet in rpm package ovirt-engine-backend-3.3.0-15.fc17.noarch 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: Script sink: /var/tmp/rpm-tmp.J0HyUz: line 1: fg: no job control error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet failed, exit status 1 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: Done: ovirt-engine-backend-3.3.0-15.fc17.noarch Second attempt: 2013-04-10 15:12:11::DEBUG::common_utils::347::root:: YUM: VERB: Building transaction 2013-04-10 15:12:12::ERROR::common_utils::355::root:: YUM: FAIL: [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires ovirt-engine = 3.3.0-14.fc17'] 2013-04-10 15:12:12::DEBUG::common_utils::347::root:: YUM: VERB: Performing rollback 2013-04-10 15:12:12::DEBUG::common_utils::1410::root:: Locking rpms in yum-version-lock 2013-04-10 15:12:12::ERROR::engine-upgrade::1299::root:: Traceback (most recent call last): File "/bin/engine-upgrade", line 1292, in <module> main(options) File "/bin/engine-upgrade", line 1142, in main runFunc([rhyum.begin], MSG_INFO_CHECK_UPDATE) File "/bin/engine-upgrade", line 617, in runFunc func() File "/bin/engine-upgrade", line 310, in begin self.emptyTransaction = not self._miniyum.buildTransaction() File "/usr/share/ovirt-engine/scripts/miniyum.py", line 761, in buildTransaction raise yum.Errors.YumBaseError(msg) YumBaseError: [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires ovirt-engine = 3.3.0-14.fc17'] Realizing things were now hosed: [root@ovirtfoo /]# yum erase ovirt-* otopi-* Loaded plugins: langpacks, presto, refresh-packagekit, versionlock Resolving Dependencies --> Running transaction check ---> Package otopi.noarch 0:3.3.0-15.fc17 will be erased ---> Package otopi-java.noarch 0:3.3.0-15.fc17 will be erased ---> Package ovirt-engine.noarch 0:3.3.0-14.fc17 will be erased ---> Package ovirt-engine-backend.noarch 0:3.3.0-14.fc17 will be erased ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be erased ---> Package ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 will be erased ---> Package ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 will be erased ---> Package ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 will be erased ---> Package ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 will be erased ---> Package ovirt-engine-setup.noarch 0:3.3.0-15.fc17 will be erased ---> Package ovirt-engine-tools.noarch 0:3.3.0-14.fc17 will be erased ---> Package ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 will be erased ---> Package ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 will be erased ---> Package ovirt-host-deploy.noarch 0:3.3.0-15.fc17 will be erased ---> Package ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 will be erased ---> Package ovirt-image-uploader.noarch 0:3.3.0-15.fc17 will be erased ---> Package ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 will be erased ---> Package ovirt-log-collector.noarch 0:3.3.0-15.fc17 will be erased --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Removing: otopi noarch 3.3.0-15.fc17 @ovirt-engine 463 k otopi-java noarch 3.3.0-15.fc17 @ovirt-engine 27 k ovirt-engine noarch 3.3.0-14.fc17 @ovirt-engine 1.3 M ovirt-engine-backend noarch 3.3.0-14.fc17 @ovirt-engine 20 M ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M ovirt-engine-cli noarch 3.3.0.1-15.fc17 @ovirt-engine 557 k ovirt-engine-dbscripts noarch 3.3.0-14.fc17 @ovirt-engine 816 k ovirt-engine-restapi noarch 3.3.0-14.fc17 @ovirt-engine 1.0 M ovirt-engine-sdk noarch 3.3.0.1-15.fc17 @ovirt-engine 3.1 M ovirt-engine-setup noarch 3.3.0-15.fc17 @ovirt-engine 653 k ovirt-engine-tools noarch 3.3.0-14.fc17 @ovirt-engine 178 k ovirt-engine-userportal noarch 3.3.0-14.fc17 @ovirt-engine 23 M ovirt-engine-webadmin-portal noarch 3.3.0-14.fc17 @ovirt-engine 32 M ovirt-host-deploy noarch 3.3.0-15.fc17 @ovirt-engine 211 k ovirt-host-deploy-java noarch 3.3.0-15.fc17 @ovirt-engine 11 k ovirt-image-uploader noarch 3.3.0-15.fc17 @ovirt-engine 923 k ovirt-iso-uploader noarch 3.3.0-15.fc17 @ovirt-engine 98 k ovirt-log-collector noarch 3.3.0-15.fc17 @ovirt-engine 133 k Transaction Summary ================================================================================ Remove 18 Packages Installed size: 104 M Is this ok [y/N]: y Downloading Packages: Running Transaction Check Running Transaction Test Transaction Test Succeeded Running Transaction Erasing : ovirt-engine-backend.noarch 1/18 Erasing : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 2/18 Erasing : ovirt-engine-restapi-3.3.0-14.fc17.noarch 3/18 Erasing : ovirt-engine-setup-3.3.0-15.fc17.noarch 4/18 Erasing : ovirt-engine-tools-3.3.0-14.fc17.noarch 5/18 Erasing : ovirt-engine-userportal-3.3.0-14.fc17.noarch 6/18 Erasing : ovirt-engine-3.3.0-14.fc17.noarch 7/18 warning: /etc/ovirt-engine/engine.conf saved as /etc/ovirt-engine/engine.conf.rpmsave Erasing : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch 8/18 Erasing : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 9/18 Erasing : otopi-java-3.3.0-15.fc17.noarch 10/18 Erasing : ovirt-host-deploy-3.3.0-15.fc17.noarch 11/18 Erasing : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 warning: /etc/ovirt-engine/imageuploader.conf saved as /etc/ovirt-engine/imageuploader.conf.rpmsave Erasing : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 warning: /etc/ovirt-engine/isouploader.conf saved as /etc/ovirt-engine/isouploader.conf.rpmsave Erasing : ovirt-log-collector-3.3.0-15.fc17.noarch 14/18 warning: /etc/ovirt-engine/logcollector.conf saved as /etc/ovirt-engine/logcollector.conf.rpmsave Erasing : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 15/18 Erasing : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 16/18 Erasing : otopi-3.3.0-15.fc17.noarch 17/18 Error in PREUN scriptlet in rpm package ovirt-engine-backend /var/tmp/rpm-tmp.uFqX1f: line 1: fg: no job control error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet failed, exit status 1 Verifying : otopi-3.3.0-15.fc17.noarch 1/18 Verifying : otopi-java-3.3.0-15.fc17.noarch 2/18 Verifying : ovirt-log-collector-3.3.0-15.fc17.noarch 3/18 Verifying : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch 4/18 Verifying : ovirt-host-deploy-3.3.0-15.fc17.noarch 5/18 Verifying : ovirt-engine-tools-3.3.0-14.fc17.noarch 6/18 Verifying : ovirt-engine-setup-3.3.0-15.fc17.noarch 7/18 Verifying : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 8/18 Verifying : ovirt-engine-restapi-3.3.0-14.fc17.noarch 9/18 Verifying : ovirt-engine-userportal-3.3.0-14.fc17.noarch 10/18 Verifying : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 11/18 Verifying : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 Verifying : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 Verifying : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 14/18 ovirt-engine-backend-3.3.0-15.fc17.noarch was supposed to be removed but is not! Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 15/18 Verifying : ovirt-engine-backend-3.3.0-14.fc17.noarch 16/18 Verifying : ovirt-engine-3.3.0-14.fc17.noarch 17/18 Verifying : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 18/18 Removed: otopi.noarch 0:3.3.0-15.fc17 otopi-java.noarch 0:3.3.0-15.fc17 ovirt-engine.noarch 0:3.3.0-14.fc17 ovirt-engine-backend.noarch 0:3.3.0-14.fc17 ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 ovirt-engine-setup.noarch 0:3.3.0-15.fc17 ovirt-engine-tools.noarch 0:3.3.0-14.fc17 ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 ovirt-host-deploy.noarch 0:3.3.0-15.fc17 ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 ovirt-image-uploader.noarch 0:3.3.0-15.fc17 ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 ovirt-log-collector.noarch 0:3.3.0-15.fc17 Failed: ovirt-engine-backend.noarch 0:3.3.0-15.fc17 Complete! [root@ovirtfoo /]# rpm -qa | grep oto protobuf-java-2.4.1-12.fc17.x86_64 libgphoto2-2.4.14-1.fc17.x86_64 [root@ovirtfoo /]# rpm -qa | grep ovirt ovirt-engine-backend-3.3.0-15.fc17.noarch [root@ovirtfoo /]# yum erase ovirt-engine-backend-3.3.0-15.fc17.noarch Loaded plugins: langpacks, presto, refresh-packagekit, versionlock Resolving Dependencies --> Running transaction check ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be erased --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Removing: ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M Transaction Summary ================================================================================ Remove 1 Package Installed size: 20 M Is this ok [y/N]: y Downloading Packages: Running Transaction Check Running Transaction Test Transaction Test Succeeded Running Transaction Error in PREUN scriptlet in rpm package ovirt-engine-backend-3.3.0-15.fc17.noarch /var/tmp/rpm-tmp.jq1b7e: line 1: fg: no job control error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet failed, exit status 1 Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 1/1 Failed: ovirt-engine-backend.noarch 0:3.3.0-15.fc17 Complete! - DHC

2 14

[Engine-devel] watchdog
by Laszlo Hornyak 14 Apr '13

14 Apr '13

Hi, A new version of the watchdög feature is available in gerrit: http://gerrit.ovirt.org/13057 - db http://gerrit.ovirt.org/13058 - bll http://gerrit.ovirt.org/13059 - frontend http://gerrit.ovirt.org/13060 - rest http://www.ovirt.org/Features/Watchdog_engine_support Since the last update the patchset has gone through major changes to meet the new architectureal and functional requirements. Also because of the rewrite this is again a preview version under testing with some missing functionality, therefore I re-introduced the [wip] flag on it. Thx, Laszlo

7 16

[Engine-devel] oVirt history; now in starwars!
by Doron Fediuck 14 Apr '13

14 Apr '13

Here's a better way to see the project history: Engine http://starlogs.net/#oVirt/ovirt-engine VDSM http://starlogs.net/#oVirt/vdsm

1 0

[Engine-devel] New feature in UI Plugins available: Cross-window communication support
by Vojtech Szocs 12 Apr '13

12 Apr '13

------=_Part_3194251_135392542.1365790423090 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hello everyone, we just introduced support for cross-window (cross-origin, a.k.a. cross-domain) communication that can be utilized by UI plugins. Custom content contributed by the UI plugin (e.g. via tab or dialog) can send arbitrary messages back to given plugin(s) via WebAdmin (parent) window. The implementation is based on HTML5 window.postMessage API that triggers 'message' events on the target window. WebAdmin takes care of intercepting such messages, performing source origin check per each plugin, and passing message data to plugin(s) as appropriate. With this feature, custom content can directly and transparently control/notify given UI plugin(s). Aside from content --> plugin message passing, the message data received by the plugin also contains reference to source window, i.e. custom content that sent the message. This can be used to establish two-way communication between custom content window and plugin code. For example, custom HTML content contributed by the plugin uses JavaScript to send the message: // 'parent' refers to WebAdmin window. // Most browsers support sending String messages, e.g. 'Foo Bar'. // Modern browsers support sending Object messages, e.g. {'foo':'bar'}. // The second argument is target origin that should match WebAdmin (Engine) origin. // You can also use '*' (any origin) as per HTML5 spec, however this is not a good practice. parent.postMessage('Foo Bar', 'http://engine-host:1234'); Sample UI plugin that receives the message: <snippet> var api = parent.pluginApi('showcase'); // New bootstrap sequence function: provide custom API options object. // This is completely optional, there are always sensible fallback values. api.options({ // Specify allowed source origin(s) from which messages will be accepted. // Can be either string (single origin) or string array (multiple origins). // Can be '*' (any origin) as per HTML5 spec, however this is not a good practice. // Default value is empty array (reject all messages). allowedMessageOrigins: ['http://content-host:80','http://content-host:443'] }); api.register({ UiInit: function() { // Assume the dialog content takes care of sending the message. api.showDialog(...); }, // New event handler function: process message event. // Called *only* after passing source origin check, based on 'allowedMessageOrigins'. MessageReceived: function(data, sourceWindow) { // Parse and interpret data // Optionally, interact with sourceWindow (content that sent the message) } }); api.ready(); </snippet> Attached you can find a sample UI plugin that demonstrates this new feature via custom dialog. Regards, Vojtech ------=_Part_3194251_135392542.1365790423090 Content-Type: application/x-compressed-tar; name=sample-cross-window-messaging-plugin.tar.gz Content-Disposition: attachment; filename=sample-cross-window-messaging-plugin.tar.gz Content-Transfer-Encoding: base64 H4sIAGdOaFEAA+2X34/aOBDHeYW/ws2L4bqQHxuSigLS9dqT+lBt1e6pOp36YBID3oY4sh0ot+J/ v3GcbOnuIvZHtVV1/vDgZDIe2zOTb4QkqyKj/URwKfsblqd8019RKcmC5Yt+kZUwuq3H4QFxPDRj FH431rT8wD+FX+j7Qcvz49jzW2j4yHXvRCkVEQi11vJfnsjDfsee/6LIu9RfLvkmIZL25yyj8t7t UNV7eLz+gRfG/in4BUEUhLb+T8G96j+4kDy//xq6wFEYHqy/H0VQfy8+PfX9YVjVPwyGLeT9+OPe 5H9e/8tOp+3kZEWdEXKaOjsnYCxFpm3uhs5IuoIuuLq41hWuzqAaLNUqqyYKKnkpEvqeqOV+VKMe Tqez6/zsU1saHqL/3+p9tzWOvP8+cE3/wyj07fv/FIyfvT774/zv92+Qrue0M24GSlIYZCJYoZDa FnSCFf2q3AuyJsaKp6Ada0geKRiaoIIImquBaZnfC9bFTdvg3kvwBK8BLxTjuexedtpt10XvyBeK ZCkoUhzJgiZsvkWm+8BO85QKxAWDeF3ZQ0sqKMwjWcY3NH1n3M6qx3KE/sFLpYqR6/pBPPDg5+OT G6bRi9jz8OdOe3e1JUEXTCoqqj39xd7mTI3QvMwTvdNuD2lz5ahP85qRjC+6+JxKhcwNPkGQGKn6 6dXtHSTTOPcLLlV93up90rNfeF7xVV9E1QVstN3ega626xN/oAlla5ru7TIlipwgo7qfqne43rd5 oQcko0J18Y0AGD1Heq5Z4/uskHTb1bdj11QbmsGtm2LG0+107FaDtlYd87Mb2fIgHqL/B5r34BpH 9T8aNvofVfYghv+CVv+fgsfqf6NBaEGV0eJaMwVVpchRypNypb8L8PxNRvXlq+3btIuNruPeYE2y koIA7V7uh9Pq/1EJaMJateqwzVcGeq95gP/kHL0iAjRzbxO9W0OezS5ooo6GvMRzzvEIzyDq7taw N2URcuZPP9Es4avqe7b3jXgGPr72KMA9IzOaoTkXE8fkwJmeEwFLILPGaOxWLtMxy4uyzr2jc+8g ll5NQlXeJs5vjt5C0USflUrBWXmeZCz5MnFuyaMz/QhGZKyoNoOcVzOPBruWwTqYsR4MZr8VFovF YrFYLBaLxWKxWCwWi8Xy1PwHbpTX7gAoAAA= ------=_Part_3194251_135392542.1365790423090--

1 0

[Engine-devel] ovirt-host-deploy and multible bridges
by Sahina Bose 11 Apr '13

11 Apr '13

This is a multi-part message in MIME format. --------------080204010900060200040902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I'm testing the bootstrapping of host without reboot on Fedora 18. After host's bootstrap, Ifconfig output returns this: ovirtmgmt: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.70.37.219 netmask 255.255.254.0 broadcast 10.70.37.255 <snipped> virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 <snipped> Running*glusterHostsList* vdsm verb, returns the ip address 192.168.122.1, whereas my host has been added with ip address 10.70.37.219 If I reboot the host, the virbr0 bridge is removed, and there's no issue. The vdsm verb glusterHostsList - returns ipAddress of host + output of gluster peer probe. This is needed because a periodic sync job needs to make sure that the hosts added in engine are in sync with the gluster cli (hosts could also be added/removed from gluster cli). How can we make sure glusterHostsList picks the correct ipAddress? Reading the inetinfo based on bridge has been vetoed as we are doing away with bridges. It would also work if virbr0 was updated in vds_interfaces table. Since this is not happening either - we have an issue. thanks sahina --------------080204010900060200040902 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"> <pre>Hi all, I'm testing the bootstrapping of host without reboot on Fedora 18. After host's bootstrap, Ifconfig output returns this: ovirtmgmt: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.70.37.219 netmask 255.255.254.0 broadcast 10.70.37.255 <snipped> virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 <snipped> Running *glusterHostsList* vdsm verb, returns the ip address 192.168.122.1, whereas my host has been added with ip address 10.70.37.219 If I reboot the host, the virbr0 bridge is removed, and there's no issue. </pre> The vdsm verb glusterHostsList - returns ipAddress of host + output of gluster peer probe. This is needed because a periodic sync job needs to make sure that the hosts added in engine are in sync with the gluster cli (hosts could also be added/removed from gluster cli). How can we make sure glusterHostsList picks the correct ipAddress? Reading the inetinfo based on bridge has been vetoed as we are doing away with bridges. It would also work if virbr0 was updated in vds_interfaces table. Since this is not happening either - we have an issue. thanks sahina </body> </html> --------------080204010900060200040902--

3 11

[Engine-devel] build stuck on RunVmCommandTest
by Shireesh Anjal 10 Apr '13

10 Apr '13

This is a multi-part message in MIME format. --------------050101090103000106050901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------050101090103000106050901 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, 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 </body> </html> --------------050101090103000106050901--

4 8

[Engine-devel] Added support for POSIX and GNU long parameters to engine-manage-domains
by Martin Perina 10 Apr '13

10 Apr '13

Hi, I've created a patch that adds support for POSIX and GNU long paramaters. Patch is using argparse4j library (argparse4j.sourceforge.net) which suites our needs in my opinion better than other libraries I've tested (JCommander, commons-cli, args4j). Patch includes these changes: 1) "-action" parameter has been removed, each action is specified directly, for example "engine-manage-domains list" 2) "-interactive" parameter has been removed, if "--passwordFile" parameter is not specified, then the password will be read interactively 3) "-addPermissions" parameter has been rename to "--superuser" with "-s" short version 4) Each parameter has POSIX variant ("-p PROVIDER") and corresponding GNU long variant ("--provider=PROVIDER") 5) Commands and parameters names can be abbreviated as long as the abbreviation is unambiguous (for example "list" command can be specified like "engine-manage-domains l") So for example command to create a domain now may look like this: engine-manage-domains add -d xyz.com -p IPA -u admin engine-manage-domains add --domain=xyz.com --provider=IPA --user=admin engine-manage-domains a -d xyz.com -p ipa --user=admin All variants do the same. If you're interested, please review the patch: http://gerrit.ovirt.org/#/c/13776/ Regards Martin Perina

1 0

[Engine-devel] compilation stuck on RemoveSnapshotCommandTest?
by Einav Cohen 09 Apr '13

09 Apr '13

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"]

2 5

[Engine-devel] Java 7, revisited again
by Allon Mureinik 09 Apr '13

09 Apr '13

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, 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.

2 3