April 2013 - Devel - oVirt List Archives

Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9
by Chen, Wei D 18 Apr '13

18 Apr '13

Hi Doron and Ofri, Thanks for your reply, here is some other question. ii. When adding a host into the trusted cluster, the host will be attested via OAT service, only trusted hosted can be added. Would you also kindly tell me if there is any mandatory logic check when adding a host into a cluster, so we can also put attestation logic with these mandatory check together? Some example or code location is better. Thanks a lot. Best Regards, Dave Chen -----Original Message----- From: Doron Fediuck [mailto:dfediuck@redhat.com] Sent: Wednesday, April 10, 2013 8:03 PM To: Ofri Masad Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan Subject: Re: minutes for sync up on Open Attestation integration with oVirt in 4/9 ----- Original Message ----- > From: "Ofri Masad" <omasad(a)redhat.com> > To: "Gang Wei" <gang.wei(a)intel.com> > Cc: "Wei D Chen" <wei.d.chen(a)intel.com>, "Buddy Cao" > <buddy.cao(a)intel.com>, "Lijuan Zhang" <lijuan.zhang(a)intel.com>, "Doron > Fediuck" <dfediuck(a)redhat.com> > Sent: Wednesday, April 10, 2013 2:23:57 PM > Subject: Re: minutes for sync up on Open Attestation integration with > oVirt in 4/9 > > Hi, > > answers inside the mail body. > > ----- Original Message ----- > > From: "Doron Fediuck" <dfediuck(a)redhat.com> > > To: "Wei D Chen" <wei.d.chen(a)intel.com> > > Cc: "Gang Wei" <gang.wei(a)intel.com>, "Buddy Cao" > > <buddy.cao(a)intel.com>, "Lijuan Zhang" <lijuan.zhang(a)intel.com>, > > "Ofri Masad" <omasad(a)redhat.com> > > Sent: Wednesday, April 10, 2013 12:12:26 PM > > Subject: Re: minutes for sync up on Open Attestation integration > > with oVirt in 4/9 > > > > Hi Dave, > > Adding Ofri to answer your questions. > > > > ----- Original Message ----- > > > From: "Wei D Chen" <wei.d.chen(a)intel.com> > > > To: "Gang Wei" <gang.wei(a)intel.com>, "Doron Fediuck" > > > <dfediuck(a)redhat.com>, > > > "Buddy Cao" <buddy.cao(a)intel.com>, "Lijuan Zhang" > > > <lijuan.zhang(a)intel.com> > > > Sent: Wednesday, April 10, 2013 6:31:05 AM > > > Subject: RE: minutes for sync up on Open Attestation integration > > > with oVirt in 4/9 > > > > > > Hi Doron, > > > > > > > > > iii. Then periodic trust check will be added into background process > > > for > > > all existing hosts, once becoming non-trusted, mark it as > > > non-operational. > > > > > > - [Dave] Would you give me some details about the “background > > > process” mentioned in our sync up meeting? What’s the process and > > > where is related code? > > > > > The use Quartz Job to scheduled background processes. > An example can be found in: > ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: > 222) > > This code calls a method that is located in: > ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engin > e/core/bll/quota/QuotaManager.java > (Line: 1000) > the @OnTimerMethodAnnotation annotation and the unique job name > connects the two in runtime. > > The job can query the attestation server for all the host and then set > untrusted hosts to Non-Operational. > the best way would be to call SetNonOperationalVdsCommand with a new > NonOperationalReason. > This command tries to migrate all VMs from the host and then set it > non operational. > (We need to think about non-migrational VMs - should we close those > VMs or keep the host running) > One more thing you may want to consider; If we get a positive response for a host which is currently non-operational, issue an activate command to try and make it operational again. Alternatively, you may decide not to handle it, assuming untrusted hosts can only be activated manually (see below Ofri's response on activating a host). > > > > > > iv. If admin fixed the non-operational node and try to switch it to > > > operational mode again, a trust check will happen to gate the switching. > > > > > > - [Dave] If there is a button provided from UI for checking the > > > logic? or we need add an extra-button for attestation check only? > > > > > In the UI we already have the "Activate" option. What still needs to > be added is the check with the attestation provider to make sure that > if the cluster is defined 'Trusted'. If so, only trusted host will > succeed in the activate command (and, of course, a proper Audit Log > error in case the host failed to activate due to trust issue. > > the correct place to add this check would be in: > ovirt-engine/backend/manager/modules/vdsbroker/src/main/java/org/ovirt > /engine/core/vdsbroker/VdsManager.java:activate() > this is where the re-activation process begins. > > > > > > > Thanks very much. > > > > > > > > > > > > Best Regards, > > > Dave Chen

6 17

[Engine-devel] How get all language WebAdm ?
by 李强 18 Apr '13

18 Apr '13

HI：All I install ovirt engine and open IE9 to manage. But I select Chinese language UI to display and failed. The UI's language always is Englisth and covers to Other language failed. OS:federa 18. Ovirt-Engine:3.2 MEM Size:4G DIsk:60G CPU:intel i7 Manage OS:Win7 Sp1 Manage IE:9 Can you help me? Thanks,

5 10

Re: [Engine-devel] [vdsm] Adding vdsm_api support for gluster vdsm verbs
by Aravinda 17 Apr '13

17 Apr '13

[Adding engine-devel] On 04/16/2013 02:10 PM, Aravinda wrote: > > vdsm/gluster is vdsm plugin for gluster related functionality. These > functionalities are available only when vdsm-gluster package is > installed. So the schema JSON of vdsm-gluster cannot be added to the > same file(vdsm_api/vdsmapi-schema.json) > > Looks like vdsm_api is not providing plugin support. This patch adds > functionality to vdsm_api to read vdsmapi-gluster-schema.json if > available. But with this approach we need to edit the core vdsmapi.py > file. > > http://gerrit.ovirt.org/#/c/13921/ > > Alternate approach: > We can have "vdsm_api/plugins" or "vdsm_api/schema" directory inside > vdsm_api, so that we can modify vdsmapi.py to read all schema files > from that dir. When vdsm-gluster package installed, it copies > vdsmapi-gluster-schema.json into schema directory. > > > -- > regards > Aravinda > > > On 04/15/2013 04:14 PM, Aravinda wrote: >> Hi, >> >> We are trying to add json rpc support for vdsm gluster verbs. I >> submitted a patch to read gluster verbs schema from vdsm/gluster >> directory. >> http://gerrit.ovirt.org/#/c/13921/ >> >> Let me know if the approach is fine. >> >> -- >> regards >> Aravinda >> _______________________________________________ >> vdsm-devel mailing list >> vdsm-devel(a)lists.fedorahosted.org >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

2 2

[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