Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9
by Chen, Wei D
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
11 years, 7 months
[Engine-devel] How get all language WebAdm ?
by 李强
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,
11 years, 7 months
Re: [Engine-devel] [vdsm] Adding vdsm_api support for gluster vdsm verbs
by Aravinda
[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
11 years, 7 months
[Engine-devel] Starting a new translation
by Alex Ont
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
11 years, 7 months
[Engine-devel] upgrade failing with latest master
by Dead Horse
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
11 years, 7 months
[Engine-devel] New feature in UI Plugins available: Cross-window communication support
by Vojtech Szocs
------=_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--
11 years, 7 months
[Engine-devel] ovirt-host-deploy and multible bridges
by Sahina Bose
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><font face="sans-serif">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 <b class="moz-txt-star"><span class="moz-txt-tag">*</span>glusterHostsList<span class="moz-txt-tag">*</span></b> 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.</font>
<font face="sans-serif">
</font></pre>
<font face="sans-serif">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</font> are in sync with the gluster cli (hosts could
also be added/removed from gluster cli).<br>
<br>
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.<br>
<br>
It would also work if virbr0 was updated in vds_interfaces table.
Since this is not happening either - we have an issue.<br>
<br>
thanks<br>
sahina<br>
<br>
</body>
</html>
--------------080204010900060200040902--
11 years, 7 months
[Engine-devel] build stuck on RunVmCommandTest
by Shireesh Anjal
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,<br>
<br>
From last night onwards, my mvn build is getting stuck for a long
time ( > 30 minutes) on RunVmCommandTest<br>
<br>
Running org.ovirt.engine.core.bll.MoveDisksCommandTest<br>
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04
sec<br>
<b>Running org.ovirt.engine.core.bll.RunVmCommandTest</b><b><br>
</b><b>Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time
elapsed: 1,983.033 sec</b><b><br>
</b>Running org.ovirt.engine.core.bll.lock.InMemoryLockManagerTest<br>
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.007 sec<br>
Running org.ovirt.engine.core.bll.RemoveImageCommandTest<br>
<br>
The same issue is happening on one of my colleague's system as well.
Any help in fixing this will be highly appreciated.<br>
<br>
Regards,<br>
Shireesh<br>
</body>
</html>
--------------050101090103000106050901--
11 years, 7 months
