Re: [ovirt-devel] Empty Dropdown Menus in Webadmin

[Phillip Bailey]

On Tue, May 31, 2016 at 1:14 PM, Alexander Wels  wrote:

> After rebasing and recompiling did you re-run engine-setup, its highly
> likely
> some tables or something changed and you are seeing errors in the log due
> to
> not having run engine-setup.
>

Alex/Vojtech,

Disregard. The issue seems to have resolved itself, which is odd since I
didn't restart the engine. It was a fresh install, so it was a brand new
database and I had run setup prior to starting the engine. If the issue
occurs again, I'll make sure to take some screenshots.

Thanks for the help and sorry for the false alarm.


>
> On Tuesday, May 31, 2016 10:01:02 AM Vojtech Szocs wrote:
> > Hi Phillip,
> >
> > can you please share some screenshots?
>
>
> > Thanks,
> > Vojtech
> >
> >
> > - Original Message -
> >
> > > From: "Phillip Bailey" 
> > > To: devel@ovirt.org
> > > Sent: Tuesday, May 31, 2016 2:47:31 PM
> > > Subject: [ovirt-devel] Empty Dropdown Menus in Webadmin
> > >
> > > Hi,
> > >
> > > Is anyone else experiencing empty dropdown menus in webadmin? I started
> > > having the problem after rebasing Friday afternoon. I rebased again
> this
> > > morning, but am still experiencing the same problem. I'm trying to
> > > determine whether this is something isolated to my environment, or a
> more
> > > widespread issue.
> > >
> > > I appreciate any advice any of you may be able to offer.
> > >
> > > Thanks!
> > >
> > > -Phillip Bailey
> > >
> > > ___
> > > Devel mailing list
> > > Devel@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/devel
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Interacting with VDSM storage without oVirt Engine

[Hayley Swimelar]

On 05/31/2016 12:15 PM, Yaniv Dary wrote:

Have you considered submitting a design document to the oVirt website.
We will be happy to help in making this happen.



I believe there is already one here: 
http://www.ovirt.org/develop/release-management/features/infra/drbd/


I would be happy to update it as that was written for DRBD 8.4 and I'm 
working with DRBD 9.




On Tue, May 31, 2016 at 8:54 PM, Hayley Swimelar  wrote:




On 05/31/2016 10:40 AM, Nir Soffer wrote:


On Tue, May 31, 2016 at 7:25 PM, Hayley Swimelar 
wrote:




On 05/31/2016 08:25 AM, Yaniv Dary wrote:



Can you explain the use case? What are you trying to use VDSM for?
The API you want to use is internal and can break without notice.




Hi Yaniv,

I'm working to to integrate DRBD storage into VDSM.

It will be a new type of storage domain, so I can't use the GUI since the
engine component won't be aware of it as far as I can tell.

The current plan is to have another developer on our end make changes to
the
Engine once the VDSM side is working.



Hi Hayley,

Sounds cool, can you describe in more details the use case, and how do
you think this
can work?



Hi Nir,

The use case is to make replicated block level storage available in oVirt.

VDSM should be able to communicate with DRBD via DRBD Manage, which is a
new administrative layer for the latest release.

Cheers,

Nir



--
Hayley Swimelar
LINBIT | Keeping the Digital World Running
DRBD — Corosync — Pacemaker
+1-503-573-1262 x212
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel





--
Hayley Swimelar
LINBIT | Keeping the Digital World Running
DRBD — Corosync — Pacemaker
+1-503-573-1262 x212
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Interacting with VDSM storage without oVirt Engine

[Yaniv Dary]

Have you considered submitting a design document to the oVirt website.
We will be happy to help in making this happen.

Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109

Tel : +972 (9) 7692306
8272306
Email: yd...@redhat.com
IRC : ydary


On Tue, May 31, 2016 at 8:54 PM, Hayley Swimelar  wrote:

>
>
> On 05/31/2016 10:40 AM, Nir Soffer wrote:
>
>> On Tue, May 31, 2016 at 7:25 PM, Hayley Swimelar 
>> wrote:
>>
>>>
>>>
>>> On 05/31/2016 08:25 AM, Yaniv Dary wrote:
>>>

 Can you explain the use case? What are you trying to use VDSM for?
 The API you want to use is internal and can break without notice.

>>>
>>>
>>> Hi Yaniv,
>>>
>>> I'm working to to integrate DRBD storage into VDSM.
>>>
>>> It will be a new type of storage domain, so I can't use the GUI since the
>>> engine component won't be aware of it as far as I can tell.
>>>
>>> The current plan is to have another developer on our end make changes to
>>> the
>>> Engine once the VDSM side is working.
>>>
>>
>> Hi Hayley,
>>
>> Sounds cool, can you describe in more details the use case, and how do
>> you think this
>> can work?
>>
>>
> Hi Nir,
>
> The use case is to make replicated block level storage available in oVirt.
>
> VDSM should be able to communicate with DRBD via DRBD Manage, which is a
> new administrative layer for the latest release.
>
> Cheers,
>> Nir
>>
>
> --
> Hayley Swimelar
> LINBIT | Keeping the Digital World Running
> DRBD — Corosync — Pacemaker
> +1-503-573-1262 x212
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Interacting with VDSM storage without oVirt Engine

[Hayley Swimelar]

On 05/31/2016 10:40 AM, Nir Soffer wrote:

On Tue, May 31, 2016 at 7:25 PM, Hayley Swimelar  wrote:



On 05/31/2016 08:25 AM, Yaniv Dary wrote:


Can you explain the use case? What are you trying to use VDSM for?
The API you want to use is internal and can break without notice.



Hi Yaniv,

I'm working to to integrate DRBD storage into VDSM.

It will be a new type of storage domain, so I can't use the GUI since the
engine component won't be aware of it as far as I can tell.

The current plan is to have another developer on our end make changes to the
Engine once the VDSM side is working.


Hi Hayley,

Sounds cool, can you describe in more details the use case, and how do
you think this
can work?



Hi Nir,

The use case is to make replicated block level storage available in oVirt.

VDSM should be able to communicate with DRBD via DRBD Manage, which is a 
new administrative layer for the latest release.



Cheers,
Nir


--
Hayley Swimelar
LINBIT | Keeping the Digital World Running
DRBD — Corosync — Pacemaker
+1-503-573-1262 x212
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Interacting with VDSM storage without oVirt Engine

[Nir Soffer]

On Tue, May 31, 2016 at 7:25 PM, Hayley Swimelar  wrote:
>
>
> On 05/31/2016 08:25 AM, Yaniv Dary wrote:
>>
>> Can you explain the use case? What are you trying to use VDSM for?
>> The API you want to use is internal and can break without notice.
>
>
> Hi Yaniv,
>
> I'm working to to integrate DRBD storage into VDSM.
>
> It will be a new type of storage domain, so I can't use the GUI since the
> engine component won't be aware of it as far as I can tell.
>
> The current plan is to have another developer on our end make changes to the
> Engine once the VDSM side is working.

Hi Hayley,

Sounds cool, can you describe in more details the use case, and how do
you think this
can work?

Cheers,
Nir

>
>
>>
>> Yaniv Dary
>> Technical Product Manager
>> Red Hat Israel Ltd.
>> 34 Jerusalem Road
>> Building A, 4th floor
>> Ra'anana, Israel 4350109
>>
>> Tel : +972 (9) 7692306
>> 8272306
>> Email: yd...@redhat.com
>> IRC : ydary
>>
>>
>> On Wed, May 25, 2016 at 8:29 PM, Hayley Swimelar 
>> wrote:
>>
>>>
>>>
>>> On 05/25/2016 02:00 AM, Martin Sivak wrote:
>>>
 Hi,

 I do not remember exacly, but you might check the source code of
 hosted engine's VdsmBackend where we do that too.



 https://gerrit.ovirt.org/gitweb?p=ovirt-hosted-engine-ha.git;a=blob;f=ovirt_hosted_engine_ha/lib/storage_backends.py;h=f2fbdc43d0e4afd7539a3a1de75de0cb07bdca9d;hb=a012f184584af20d3dba8038d73b8d9b447af7b3

 I think you are missing the prepareImage call.

>>>
>>> I think that prepareImage is probably the missing piece to this; however,
>>> it seems that the hosted engine's create_volume method with calls
>>> _get_volume_path which calls prepareImage.
>>>
>>> vdsClient's prepareImage command takes a volume UUID as an agrument I've
>>> tried passing the new UUID I created for the createVolume command, the
>>> UUID
>>> returned from that command, and a fresh UUID. All of these return the
>>> same
>>> error: Volume does not exist
>>>
>>> I've also tried manually creating the image directory under the storage
>>> domain directory with the same results for all commands.
>>>
>>>
>>>
 Regards

 --
 Martin Sivak
 SLA / oVirt

 On Wed, May 25, 2016 at 1:44 AM, Hayley Swimelar 
 wrote:

> Hello all,
>
> Like the title says, I need to work with VDSM's storage layer without
> involving the engine.
>
> Presently, I'm testing this with NFS domains and have been able to use
> vdsClient to create, attach, and activate a new storage domain, but I
> have
> not been able to create a new image or volume.
>
> Here are the commands I ran to get to this step, starting with a nfs
> volume
> already mounted on the machine I ran the commands on.
>
> 
> vdsClient -s host_name createStorageDomain 1
> 97338d5c-9b6f-1859-b827-e977ed082e53 cli_domain storage_server:/data
>
> vdsClient -s host_name attachStorageDomain
> 97338d5c-9b6f-1859-b827-e977ed082e53
> 0001-0001-0001-0001-033c
>
> vdsClient -s host_name activateStorageDomain
> 97338d5c-9b6f-1859-b827-e977ed082e53
> 0001-0001-0001-0001-033c
>
> vdsClient -s frodo createVolume 97338d5c-9b6f-1859-b827-e977ed082e53
> 0001-0001-0001-0001-033c
> 0288f410-71f1-4b7d-bdb7-e815a93e34ef
> 5369000 5 1 2 96d7726c-6969-40a5-84bd-0925496b6051 cli_volume
> 
>
> The last command outputs a new UUID, but there is nothing under
>
>
> /rhev/data-center/0001-0001-0001-0001-033c/97338d5c-9b6f-1859-b827-e977ed082e53/images/
> directory.
>
> If I pass createVolume an existing image/storage domain UUID, the
> command
> still outputs a new UUID, but nothing changes under the images
> directory.
>
> Is there a step that I am missing somewhere in this process?
>
> --
> Hayley Swimelar
> LINBIT | Keeping the Digital World Running
> DRBD — Corosync — Pacemaker
> +1-503-573-1262 x212
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>

>>> --
>>> Hayley Swimelar
>>> LINBIT | Keeping the Digital World Running
>>> DRBD — Corosync — Pacemaker
>>> +1-503-573-1262 x212
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>
> --
> Hayley Swimelar
> LINBIT | Keeping the Digital World Running
> DRBD — Corosync — Pacemaker
> +1-503-573-1262 x212
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [vdsm] Master build fails on f23

[Piotr Kliczewski]

vdsm build fails with:

17:18:54 Compiling './vdsm/clientIF.py'...
17:18:54 Makefile:984: recipe for target 'python3' failed
17:18:54 make: *** [python3] Error 1
17:18:54 Took 33 seconds

Thanks,
Piotr
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] stuck tests in ci

[Piotr Kliczewski]

All,

I just noticed one more build [1] which got stuck with:

15:46:40 Traceback (most recent call last):
15:46:40   File "/usr/lib64/python2.7/threading.py", line 804, in
__bootstrap_inner
15:46:40   File "/usr/lib64/python2.7/threading.py", line 757, in run
15:46:40   File
"/usr/lib/python2.7/site-packages/ioprocess/__init__.py", line 181, in
_communicate
15:46:40 : 'NoneType' object has no
attribute 'close'

Thanks,
Piotr

[1] 
http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/2380/console

On Sat, May 21, 2016 at 8:28 PM, Nir Soffer  wrote:
> The issue is non-daemon thread blocking the python process during
> shutdown of the tests.
>
> Current ioprocess does not create such thread, but we still see this
> issue today:
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/1841/console
>
> If the builds are using the latest ioprocess build (0.16.0-1), built after
> Sun May 15 21:29:24 2016 +0300, this is probably not related to ioprocess
>
> To understand this issue we need to get a stacktrace from the stuck python
> process.
>
> See relevant log bellow.
>
>
> Nir
>
> 
>
> 11:49:30 
> 
> 11:49:30 TOTAL
>  40672  2107248%
> 11:49:30 
> --
> 11:49:30 Ran 2182 tests in 147.661s
> 11:49:30
> 11:49:30 OK (SKIP=94)
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'udev_unref'" in  object at 0x7312610>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x5435350>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x5420850>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x7269910>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x5420f90>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x5419c10>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x610e610>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x6dc4d50>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x610f390>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x54195d0>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x5432510>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x6110250>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x5414750>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x5414150>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x6a33390>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x543d590>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x6ba8390>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x5432d50>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x5435a90>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x503f350>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x5420250>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x5442e90>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x503f950>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x610e7d0>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x5414d90>> ignored
> 11:49:30 Exception AttributeError: "'NoneType' object has no attribute
> 'write'" in  object at 0x543d450>> ignored
> 11:49:30 Exception in thread ioprocess communication (8008) (most
> likely raised during interpreter shutdown):
> 11:49:30 Traceback (most recent call last):
> 11:49:30   File "/usr/lib64/python2.7/threading.py", line 811, in
> __bootstrap_inner
> 11:49:30   File "/usr/lib64/python2.7/threading.py", line 764, in run
> 11:49:30   File
> 

Re: [ovirt-devel] Empty Dropdown Menus in Webadmin

[Alexander Wels]

After rebasing and recompiling did you re-run engine-setup, its highly likely 
some tables or something changed and you are seeing errors in the log due to 
not having run engine-setup.

On Tuesday, May 31, 2016 10:01:02 AM Vojtech Szocs wrote:
> Hi Phillip,
> 
> can you please share some screenshots?
> 
> Thanks,
> Vojtech
> 
> 
> - Original Message -
> 
> > From: "Phillip Bailey" 
> > To: devel@ovirt.org
> > Sent: Tuesday, May 31, 2016 2:47:31 PM
> > Subject: [ovirt-devel] Empty Dropdown Menus in Webadmin
> > 
> > Hi,
> > 
> > Is anyone else experiencing empty dropdown menus in webadmin? I started
> > having the problem after rebasing Friday afternoon. I rebased again this
> > morning, but am still experiencing the same problem. I'm trying to
> > determine whether this is something isolated to my environment, or a more
> > widespread issue.
> > 
> > I appreciate any advice any of you may be able to offer.
> > 
> > Thanks!
> > 
> > -Phillip Bailey
> > 
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Interacting with VDSM storage without oVirt Engine

[Hayley Swimelar]

On 05/31/2016 08:25 AM, Yaniv Dary wrote:

Can you explain the use case? What are you trying to use VDSM for?
The API you want to use is internal and can break without notice.


Hi Yaniv,

I'm working to to integrate DRBD storage into VDSM.

It will be a new type of storage domain, so I can't use the GUI since 
the engine component won't be aware of it as far as I can tell.


The current plan is to have another developer on our end make changes to 
the Engine once the VDSM side is working.




Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109

Tel : +972 (9) 7692306
8272306
Email: yd...@redhat.com
IRC : ydary


On Wed, May 25, 2016 at 8:29 PM, Hayley Swimelar  wrote:




On 05/25/2016 02:00 AM, Martin Sivak wrote:


Hi,

I do not remember exacly, but you might check the source code of
hosted engine's VdsmBackend where we do that too.


https://gerrit.ovirt.org/gitweb?p=ovirt-hosted-engine-ha.git;a=blob;f=ovirt_hosted_engine_ha/lib/storage_backends.py;h=f2fbdc43d0e4afd7539a3a1de75de0cb07bdca9d;hb=a012f184584af20d3dba8038d73b8d9b447af7b3

I think you are missing the prepareImage call.



I think that prepareImage is probably the missing piece to this; however,
it seems that the hosted engine's create_volume method with calls
_get_volume_path which calls prepareImage.

vdsClient's prepareImage command takes a volume UUID as an agrument I've
tried passing the new UUID I created for the createVolume command, the UUID
returned from that command, and a fresh UUID. All of these return the same
error: Volume does not exist

I've also tried manually creating the image directory under the storage
domain directory with the same results for all commands.




Regards

--
Martin Sivak
SLA / oVirt

On Wed, May 25, 2016 at 1:44 AM, Hayley Swimelar 
wrote:


Hello all,

Like the title says, I need to work with VDSM's storage layer without
involving the engine.

Presently, I'm testing this with NFS domains and have been able to use
vdsClient to create, attach, and activate a new storage domain, but I
have
not been able to create a new image or volume.

Here are the commands I ran to get to this step, starting with a nfs
volume
already mounted on the machine I ran the commands on.


vdsClient -s host_name createStorageDomain 1
97338d5c-9b6f-1859-b827-e977ed082e53 cli_domain storage_server:/data

vdsClient -s host_name attachStorageDomain
97338d5c-9b6f-1859-b827-e977ed082e53 0001-0001-0001-0001-033c

vdsClient -s host_name activateStorageDomain
97338d5c-9b6f-1859-b827-e977ed082e53 0001-0001-0001-0001-033c

vdsClient -s frodo createVolume 97338d5c-9b6f-1859-b827-e977ed082e53
0001-0001-0001-0001-033c 0288f410-71f1-4b7d-bdb7-e815a93e34ef
5369000 5 1 2 96d7726c-6969-40a5-84bd-0925496b6051 cli_volume


The last command outputs a new UUID, but there is nothing under

/rhev/data-center/0001-0001-0001-0001-033c/97338d5c-9b6f-1859-b827-e977ed082e53/images/
directory.

If I pass createVolume an existing image/storage domain UUID, the command
still outputs a new UUID, but nothing changes under the images directory.

Is there a step that I am missing somewhere in this process?

--
Hayley Swimelar
LINBIT | Keeping the Digital World Running
DRBD — Corosync — Pacemaker
+1-503-573-1262 x212
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel




--
Hayley Swimelar
LINBIT | Keeping the Digital World Running
DRBD — Corosync — Pacemaker
+1-503-573-1262 x212
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel





--
Hayley Swimelar
LINBIT | Keeping the Digital World Running
DRBD — Corosync — Pacemaker
+1-503-573-1262 x212
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ACTION REQUESTED] i18n default English text is now stored in properties files

[Yaniv Dary]

Is this change being done for 4.0? I would think this is a risky change
that better fits 4.1.

Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109

Tel : +972 (9) 7692306
8272306
Email: yd...@redhat.com
IRC : ydary


On Tue, May 24, 2016 at 6:20 PM, Scott Dickerson 
wrote:

>
>
> On Tue, May 24, 2016 at 9:28 AM, Martin Sivak  wrote:
>
>> > Are you talking about some files in specific, and if so which ones?
>>
>> # find . -name AppErrors.properties | grep -v generated | grep -v target
>>
>>
>> ./backend/manager/modules/dal/src/main/resources/bundles/AppErrors.properties
>>
>> ./frontend/webadmin/modules/frontend/src/main/resources/org/ovirt/engine/ui/frontend/AppErrors.properties
>>
>> ./frontend/webadmin/modules/userportal-gwtp/src/main/resources/org/ovirt/engine/ui/frontend/AppErrors.properties
>>
>> ./frontend/webadmin/modules/webadmin/src/main/resources/org/ovirt/engine/ui/frontend/AppErrors.properties
>>
>
> That properties file does appear 3 times on the frontend side.  It is
> quite annoying, and there is a reason for it.  I ran a process to move
> English text to properties files out of annotations, creating the
> properties files as necessary.  In this case, AppErrors.properties existed
> in both "userportal-gwtp" and "webadmin", but didn't originally exist in
> the frontend module.  Due to the way GWT i18n and GWT compiling work,
> default values from annotations on the interface would augment the
> properties values that GWT finds first on the classpath.  Since
> AppErrors.properties in "webadmin" is closer to the compiler then
> AppError.properties in "frontend", webadmin will be used.  This allows us
> to have a full set of AppErrors messages per GWT project, unique to get GWT
> project.  It still confuses me a bit.  There are better ways to do this.
>
> ConsoleErrors and VdsmErrors do the same thing.  Those 3 message bundles
> are on the list to do something about in the next round of work.  We'll
> probably create a common (App|Console|Vdsm)Errors interface, move messages
> that are the same between the user portal and the admin portal to the
> common ancestor and only define app specific keys in their respective
> projects.
>
>
>>
>> Now, I know the files are not 100% equivalent, but we were adding the
>> same messages to all of them in all the features I was working on.
>> This leads me to believe that most of the people treat them as the
>> same and we should only have one source for them.
>>
>>
> Yes, our goal is to only have 1 source for them.  It is unfortunate that
> you have to add the text in multiple places currently.  We'll get better
> (soon).
>
>
>>
>> Martin
>>
>> On Tue, May 24, 2016 at 3:17 PM, Scott Dickerson 
>> wrote:
>> > response inline
>> >
>> > On Tue, May 24, 2016 at 5:29 AM, Martin Sivak 
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> We still have three almost identical files. Can we somehow keep just
>> >> one and generate the other two? I was actually playing a bit with a
>> >> change in the opposite direction - keeping just the EngineMessages
>> >> enum with added default english translations and generating all other
>> >> files from it.
>> >
>> >
>> > Are you talking about some files in specific, and if so which ones?
>> >
>> >>
>> >> Do you think it would make sense? It would not require a test then as
>> >> the consistency would be checked during compilation phase directly.
>> >
>> >
>> > Sure, generating some code from a key/message file could be useful.  The
>> > difficulty comes in when we have Messages or Constants interface that
>> > inherit from a common ancestor.  That construct is used a few times to
>> share
>> > messages between both the user portal and the admin portal.
>> >
>> > The primary reasons this change was done was to simplify translation
>> and to
>> > better manage workflow between language files in gerrit and documents in
>> > Zanata.  With this change, there is now a 1 to 1 mapping of properties
>> files
>> > to zanata documents.  Well, for the front end i18n code at least.  The
>> > current translations for 4.0 can be seen here:
>> >
>> >https://translate.zanata.org/iteration/view/ovirt/master/documents
>> >
>> > We will be making additional i18n changes for 4.1, so any input is very
>> > welcome.
>> >
>> >>
>> >> Martin
>> >>
>> >> On Mon, May 23, 2016 at 7:38 PM, Scott Dickerson 
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > In order to resolve bug [1] and prep [2], the default English text
>> for
>> >> > I18N
>> >> > Constants and Messages have been moved to their corresponding
>> properties
>> >> > files.  Going forward, if a new constant or message needs to be
>> added,
>> >> > please add the key method to the proper interface and then add the
>> key
>> >> > plus
>> >> > English text to the interface's corresponding properties file.
>> Checks
>> >> > will
>> >> > 

Re: [ovirt-devel] oVirt Reports Portal localization

[Juliette Tux]

Thanks, Vojtech!
Found it :)

On 31 May 2016 at 16:55, Vojtech Szocs  wrote:

> Hi,
>
> I'm not the maintainer but you can clone `ovirt-reports` git repo,
> the localized messages seem to be at:
>
>   packaging/ovirt-reports/resources/reports_resources/localization
>
> In Zanata, I found a project called `Ovirt Engine Reports`:
>
>   https://translate.zanata.org/project/view/ovirt-reports-history
>
> Hope it helps.
>
> Regards,
> Vojtech
>
>
> - Original Message -
> > From: "Juliette Tux" 
> > To: Devel@ovirt.org
> > Sent: Tuesday, May 31, 2016 1:50:08 PM
> > Subject: [ovirt-devel] oVirt Reports Portal localization
> >
> > Hello gentlemen,
> > Russian localizators here :)
> >
> > Which files should we look into to be able to translate the Reports
> Portal
> > interface/messages for oVirt ver 3.x ?
> > Did not find anything relevant on Zanata in case you would like to
> redirect
> > me over there :)
> >
> > --
> > С уважением, Дронова Юлия
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>



-- 
С уважением, Дронова Юлия
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Empty Dropdown Menus in Webadmin

[Vojtech Szocs]

Hi Phillip,

can you please share some screenshots?

Thanks,
Vojtech


- Original Message -
> From: "Phillip Bailey" 
> To: devel@ovirt.org
> Sent: Tuesday, May 31, 2016 2:47:31 PM
> Subject: [ovirt-devel] Empty Dropdown Menus in Webadmin
> 
> Hi,
> 
> Is anyone else experiencing empty dropdown menus in webadmin? I started
> having the problem after rebasing Friday afternoon. I rebased again this
> morning, but am still experiencing the same problem. I'm trying to determine
> whether this is something isolated to my environment, or a more widespread
> issue.
> 
> I appreciate any advice any of you may be able to offer.
> 
> Thanks!
> 
> -Phillip Bailey
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt Reports Portal localization

[Vojtech Szocs]

Hi,

I'm not the maintainer but you can clone `ovirt-reports` git repo,
the localized messages seem to be at:

  packaging/ovirt-reports/resources/reports_resources/localization

In Zanata, I found a project called `Ovirt Engine Reports`:

  https://translate.zanata.org/project/view/ovirt-reports-history

Hope it helps.

Regards,
Vojtech


- Original Message -
> From: "Juliette Tux" 
> To: Devel@ovirt.org
> Sent: Tuesday, May 31, 2016 1:50:08 PM
> Subject: [ovirt-devel] oVirt Reports Portal localization
> 
> Hello gentlemen,
> Russian localizators here :)
> 
> Which files should we look into to be able to translate the Reports Portal
> interface/messages for oVirt ver 3.x ?
> Did not find anything relevant on Zanata in case you would like to redirect
> me over there :)
> 
> --
> С уважением, Дронова Юлия
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Empty Dropdown Menus in Webadmin

[Phillip Bailey]

Hi,

Is anyone else experiencing empty dropdown menus in webadmin? I started
having the problem after rebasing Friday afternoon. I rebased again this
morning, but am still experiencing the same problem. I'm trying to
determine whether this is something isolated to my environment, or a more
widespread issue.

I appreciate any advice any of you may be able to offer.

Thanks!

-Phillip Bailey
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] oVirt Reports Portal localization

[Juliette Tux]

Hello gentlemen,
Russian localizators here :)

Which files should we look into to be able to translate the Reports Portal
interface/messages for oVirt ver 3.x ?
Did not find anything relevant on Zanata in case you would like to redirect
me over there :)

-- 
С уважением, Дронова Юлия
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Failing MacPoolDaoTests on master

[Eyal Edri]

It shouldn't happen again since I migrated all dao-tests jobs to the new
jenkins.

On Tue, May 31, 2016 at 1:24 PM, dcaro  wrote:

> On 05/31 12:32, Eyal Edri wrote:
> > David,  can you investigate?
> > On May 31, 2016 12:29 PM, "Roman Mohr"  wrote:
> >
> > > On Tue, May 31, 2016 at 11:21 AM, Eyal Edri  wrote:
> > > > they only run on changes in :
> > > >
> > > >
> > >
> **/backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/businessentities/**
> > > > **sql
> > > > **/backend/manager/modules/dal/**
> > > >
> > >
> > > So where are the jobs for for https://gerrit.ovirt.org/#/c/58328/ for
> > > instance? They should have been triggered, right?
>
>
> So, as far as I can see, the issue there is that the dao tests that failed
> ran
> on the old jenkins, and finished before the tests on the new jenkins,
> getting
> their review value overridden (as they both use the same user).
>
> One solution would be to use different gerrit users for each of the jenkins
> instances, though the best solution imo is to move the jobs to the new
> jenkins
> (hopefully, as part of the standard ci, work in progress, not sure of the
> eta)
>
>
> > >
> > > > excluding file
> > > > **/backend/manager/modules/dal/src/main/resources/bundles/**
> > > >
> > > > On Tue, May 31, 2016 at 12:15 PM, Roman Mohr 
> wrote:
> > > >>
> > > >> On Tue, May 31, 2016 at 11:12 AM, Eyal Edri 
> wrote:
> > > >> > the dao tests 4.0 are on the new jenkins and they are running:
> > > >> >
> > > >> >
> http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_merged/
> > > >> >
> http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_created/
> > > >> >
> > > >>
> > > >> Am I missing somehting here? From my perspective it looks like they
> > > >> are never triggered.
> > > >>
> > > >> > the old one in old jenkins should be deleted.
> > > >> >
> > > >> > On Tue, May 31, 2016 at 11:57 AM, Roman Mohr 
> > > wrote:
> > > >> >>
> > > >> >> On Tue, May 31, 2016 at 10:49 AM, Roman Mohr 
> > > wrote:
> > > >> >> > On Tue, May 31, 2016 at 10:35 AM, Barak Korren <
> bkor...@redhat.com
> > > >
> > > >> >> > wrote:
> > > >> >> >>> That seems to be another issue. When building locally and on
> > > travis
> > > >> >> >>> we
> > > >> >> >>> have failing dao tests, not missing libraries.
> > > >> >> >>>
> > > >> >> >>> Further, on jenkins it seems like we are not running the DAO
> > > tests
> > > >> >> >>> since 26th of May.
> > > >> >> >>> Wrote a mail to infra list regarding that about an hour ago.
> > > >> >> >>
> > > >> >> >> Those are still running on the old Jenkins, we only created
> them
> > > on
> > > >> >> >> the new one for the new 4.0 branch.
> > > >> >> >> http://jenkins-old.ovirt.org/search/?q=dao
> > > >> >> >
> > > >> >> > Ok, the failing tests on merged master patches are there.
> > > >> >> > But we are not running tests on gerrit patches currently:
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > >
> http://jenkins-old.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_merged/
> > > >> >> >
> > > >> >> > Were they disabled deliberately?
> > > >> >> >
> > > >> >>
> > > >> >> Oh that was the wrong job. So they are enabled:
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > >
> http://jenkins-old.ovirt.org/job/ovirt-engine_master_dao-unit-tests_created/
> > > >> >>
> > > >> >> So maybe the issue is that the CI tests from old and new jenkins
> are
> > > >> >> overwriting their pluses and minuses?
> > > >> >>
> > > >> >> >>
> > > >> >> >> We are working on moving these tests into check_patch.sh so
> that
> > > we
> > > >> >> >> can neutralize environmental influences and stop having to
> give
> > > >> >> >> theses
> > > >> >> >> tests special treatment.
> > > >> >> >>
> > > >> >> >> --
> > > >> >> >> Barak Korren
> > > >> >> >> bkor...@redhat.com
> > > >> >> >> RHEV-CI Team
> > > >> >> ___
> > > >> >> Devel mailing list
> > > >> >> Devel@ovirt.org
> > > >> >> http://lists.ovirt.org/mailman/listinfo/devel
> > > >> >>
> > > >> >>
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Eyal Edri
> > > >> > Associate Manager
> > > >> > RHEV DevOps
> > > >> > EMEA ENG Virtualization R
> > > >> > Red Hat Israel
> > > >> >
> > > >> > phone: +972-9-7692018
> > > >> > irc: eedri (on #tlv #rhev-dev #rhev-integ)
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Eyal Edri
> > > > Associate Manager
> > > > RHEV DevOps
> > > > EMEA ENG Virtualization R
> > > > Red Hat Israel
> > > >
> > > > phone: +972-9-7692018
> > > > irc: eedri (on #tlv #rhev-dev #rhev-integ)
> > >
>
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
>
> --
> David Caro
>
> Red Hat S.L.
> Continuous Integration Engineer - EMEA ENG Virtualization R
>
> Tel.: +420 532 294 605
> Email: dc...@redhat.com
> IRC: 

Re: [ovirt-devel] Failing MacPoolDaoTests on master

[dcaro]

On 05/31 12:32, Eyal Edri wrote:
> David,  can you investigate?
> On May 31, 2016 12:29 PM, "Roman Mohr"  wrote:
> 
> > On Tue, May 31, 2016 at 11:21 AM, Eyal Edri  wrote:
> > > they only run on changes in :
> > >
> > >
> > **/backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/businessentities/**
> > > **sql
> > > **/backend/manager/modules/dal/**
> > >
> >
> > So where are the jobs for for https://gerrit.ovirt.org/#/c/58328/ for
> > instance? They should have been triggered, right?


So, as far as I can see, the issue there is that the dao tests that failed ran
on the old jenkins, and finished before the tests on the new jenkins, getting
their review value overridden (as they both use the same user).

One solution would be to use different gerrit users for each of the jenkins
instances, though the best solution imo is to move the jobs to the new jenkins
(hopefully, as part of the standard ci, work in progress, not sure of the eta)


> >
> > > excluding file
> > > **/backend/manager/modules/dal/src/main/resources/bundles/**
> > >
> > > On Tue, May 31, 2016 at 12:15 PM, Roman Mohr  wrote:
> > >>
> > >> On Tue, May 31, 2016 at 11:12 AM, Eyal Edri  wrote:
> > >> > the dao tests 4.0 are on the new jenkins and they are running:
> > >> >
> > >> > http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_merged/
> > >> > http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_created/
> > >> >
> > >>
> > >> Am I missing somehting here? From my perspective it looks like they
> > >> are never triggered.
> > >>
> > >> > the old one in old jenkins should be deleted.
> > >> >
> > >> > On Tue, May 31, 2016 at 11:57 AM, Roman Mohr 
> > wrote:
> > >> >>
> > >> >> On Tue, May 31, 2016 at 10:49 AM, Roman Mohr 
> > wrote:
> > >> >> > On Tue, May 31, 2016 at 10:35 AM, Barak Korren  > >
> > >> >> > wrote:
> > >> >> >>> That seems to be another issue. When building locally and on
> > travis
> > >> >> >>> we
> > >> >> >>> have failing dao tests, not missing libraries.
> > >> >> >>>
> > >> >> >>> Further, on jenkins it seems like we are not running the DAO
> > tests
> > >> >> >>> since 26th of May.
> > >> >> >>> Wrote a mail to infra list regarding that about an hour ago.
> > >> >> >>
> > >> >> >> Those are still running on the old Jenkins, we only created them
> > on
> > >> >> >> the new one for the new 4.0 branch.
> > >> >> >> http://jenkins-old.ovirt.org/search/?q=dao
> > >> >> >
> > >> >> > Ok, the failing tests on merged master patches are there.
> > >> >> > But we are not running tests on gerrit patches currently:
> > >> >> >
> > >> >> >
> > >> >> >
> > http://jenkins-old.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_merged/
> > >> >> >
> > >> >> > Were they disabled deliberately?
> > >> >> >
> > >> >>
> > >> >> Oh that was the wrong job. So they are enabled:
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > http://jenkins-old.ovirt.org/job/ovirt-engine_master_dao-unit-tests_created/
> > >> >>
> > >> >> So maybe the issue is that the CI tests from old and new jenkins are
> > >> >> overwriting their pluses and minuses?
> > >> >>
> > >> >> >>
> > >> >> >> We are working on moving these tests into check_patch.sh so that
> > we
> > >> >> >> can neutralize environmental influences and stop having to give
> > >> >> >> theses
> > >> >> >> tests special treatment.
> > >> >> >>
> > >> >> >> --
> > >> >> >> Barak Korren
> > >> >> >> bkor...@redhat.com
> > >> >> >> RHEV-CI Team
> > >> >> ___
> > >> >> Devel mailing list
> > >> >> Devel@ovirt.org
> > >> >> http://lists.ovirt.org/mailman/listinfo/devel
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Eyal Edri
> > >> > Associate Manager
> > >> > RHEV DevOps
> > >> > EMEA ENG Virtualization R
> > >> > Red Hat Israel
> > >> >
> > >> > phone: +972-9-7692018
> > >> > irc: eedri (on #tlv #rhev-dev #rhev-integ)
> > >
> > >
> > >
> > >
> > > --
> > > Eyal Edri
> > > Associate Manager
> > > RHEV DevOps
> > > EMEA ENG Virtualization R
> > > Red Hat Israel
> > >
> > > phone: +972-9-7692018
> > > irc: eedri (on #tlv #rhev-dev #rhev-integ)
> >

> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel


-- 
David Caro

Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R

Tel.: +420 532 294 605
Email: dc...@redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605


signature.asc
Description: PGP signature
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Failing MacPoolDaoTests on master

[dcaro]

On 05/31 12:32, Eyal Edri wrote:
> David,  can you investigate?


Sure

> On May 31, 2016 12:29 PM, "Roman Mohr"  wrote:
> 
> > On Tue, May 31, 2016 at 11:21 AM, Eyal Edri  wrote:
> > > they only run on changes in :
> > >
> > >
> > **/backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/businessentities/**
> > > **sql
> > > **/backend/manager/modules/dal/**
> > >
> >
> > So where are the jobs for for https://gerrit.ovirt.org/#/c/58328/ for
> > instance? They should have been triggered, right?
> >
> > > excluding file
> > > **/backend/manager/modules/dal/src/main/resources/bundles/**
> > >
> > > On Tue, May 31, 2016 at 12:15 PM, Roman Mohr  wrote:
> > >>
> > >> On Tue, May 31, 2016 at 11:12 AM, Eyal Edri  wrote:
> > >> > the dao tests 4.0 are on the new jenkins and they are running:
> > >> >
> > >> > http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_merged/
> > >> > http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_created/
> > >> >
> > >>
> > >> Am I missing somehting here? From my perspective it looks like they
> > >> are never triggered.
> > >>
> > >> > the old one in old jenkins should be deleted.
> > >> >
> > >> > On Tue, May 31, 2016 at 11:57 AM, Roman Mohr 
> > wrote:
> > >> >>
> > >> >> On Tue, May 31, 2016 at 10:49 AM, Roman Mohr 
> > wrote:
> > >> >> > On Tue, May 31, 2016 at 10:35 AM, Barak Korren  > >
> > >> >> > wrote:
> > >> >> >>> That seems to be another issue. When building locally and on
> > travis
> > >> >> >>> we
> > >> >> >>> have failing dao tests, not missing libraries.
> > >> >> >>>
> > >> >> >>> Further, on jenkins it seems like we are not running the DAO
> > tests
> > >> >> >>> since 26th of May.
> > >> >> >>> Wrote a mail to infra list regarding that about an hour ago.
> > >> >> >>
> > >> >> >> Those are still running on the old Jenkins, we only created them
> > on
> > >> >> >> the new one for the new 4.0 branch.
> > >> >> >> http://jenkins-old.ovirt.org/search/?q=dao
> > >> >> >
> > >> >> > Ok, the failing tests on merged master patches are there.
> > >> >> > But we are not running tests on gerrit patches currently:
> > >> >> >
> > >> >> >
> > >> >> >
> > http://jenkins-old.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_merged/
> > >> >> >
> > >> >> > Were they disabled deliberately?
> > >> >> >
> > >> >>
> > >> >> Oh that was the wrong job. So they are enabled:
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > http://jenkins-old.ovirt.org/job/ovirt-engine_master_dao-unit-tests_created/
> > >> >>
> > >> >> So maybe the issue is that the CI tests from old and new jenkins are
> > >> >> overwriting their pluses and minuses?
> > >> >>
> > >> >> >>
> > >> >> >> We are working on moving these tests into check_patch.sh so that
> > we
> > >> >> >> can neutralize environmental influences and stop having to give
> > >> >> >> theses
> > >> >> >> tests special treatment.
> > >> >> >>
> > >> >> >> --
> > >> >> >> Barak Korren
> > >> >> >> bkor...@redhat.com
> > >> >> >> RHEV-CI Team
> > >> >> ___
> > >> >> Devel mailing list
> > >> >> Devel@ovirt.org
> > >> >> http://lists.ovirt.org/mailman/listinfo/devel
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Eyal Edri
> > >> > Associate Manager
> > >> > RHEV DevOps
> > >> > EMEA ENG Virtualization R
> > >> > Red Hat Israel
> > >> >
> > >> > phone: +972-9-7692018
> > >> > irc: eedri (on #tlv #rhev-dev #rhev-integ)
> > >
> > >
> > >
> > >
> > > --
> > > Eyal Edri
> > > Associate Manager
> > > RHEV DevOps
> > > EMEA ENG Virtualization R
> > > Red Hat Israel
> > >
> > > phone: +972-9-7692018
> > > irc: eedri (on #tlv #rhev-dev #rhev-integ)
> >

> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel


-- 
David Caro

Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R

Tel.: +420 532 294 605
Email: dc...@redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605


signature.asc
Description: PGP signature
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Failing MacPoolDaoTests on master

[Eyal Edri]

David,  can you investigate?
On May 31, 2016 12:29 PM, "Roman Mohr"  wrote:

> On Tue, May 31, 2016 at 11:21 AM, Eyal Edri  wrote:
> > they only run on changes in :
> >
> >
> **/backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/businessentities/**
> > **sql
> > **/backend/manager/modules/dal/**
> >
>
> So where are the jobs for for https://gerrit.ovirt.org/#/c/58328/ for
> instance? They should have been triggered, right?
>
> > excluding file
> > **/backend/manager/modules/dal/src/main/resources/bundles/**
> >
> > On Tue, May 31, 2016 at 12:15 PM, Roman Mohr  wrote:
> >>
> >> On Tue, May 31, 2016 at 11:12 AM, Eyal Edri  wrote:
> >> > the dao tests 4.0 are on the new jenkins and they are running:
> >> >
> >> > http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_merged/
> >> > http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_created/
> >> >
> >>
> >> Am I missing somehting here? From my perspective it looks like they
> >> are never triggered.
> >>
> >> > the old one in old jenkins should be deleted.
> >> >
> >> > On Tue, May 31, 2016 at 11:57 AM, Roman Mohr 
> wrote:
> >> >>
> >> >> On Tue, May 31, 2016 at 10:49 AM, Roman Mohr 
> wrote:
> >> >> > On Tue, May 31, 2016 at 10:35 AM, Barak Korren  >
> >> >> > wrote:
> >> >> >>> That seems to be another issue. When building locally and on
> travis
> >> >> >>> we
> >> >> >>> have failing dao tests, not missing libraries.
> >> >> >>>
> >> >> >>> Further, on jenkins it seems like we are not running the DAO
> tests
> >> >> >>> since 26th of May.
> >> >> >>> Wrote a mail to infra list regarding that about an hour ago.
> >> >> >>
> >> >> >> Those are still running on the old Jenkins, we only created them
> on
> >> >> >> the new one for the new 4.0 branch.
> >> >> >> http://jenkins-old.ovirt.org/search/?q=dao
> >> >> >
> >> >> > Ok, the failing tests on merged master patches are there.
> >> >> > But we are not running tests on gerrit patches currently:
> >> >> >
> >> >> >
> >> >> >
> http://jenkins-old.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_merged/
> >> >> >
> >> >> > Were they disabled deliberately?
> >> >> >
> >> >>
> >> >> Oh that was the wrong job. So they are enabled:
> >> >>
> >> >>
> >> >>
> >> >>
> http://jenkins-old.ovirt.org/job/ovirt-engine_master_dao-unit-tests_created/
> >> >>
> >> >> So maybe the issue is that the CI tests from old and new jenkins are
> >> >> overwriting their pluses and minuses?
> >> >>
> >> >> >>
> >> >> >> We are working on moving these tests into check_patch.sh so that
> we
> >> >> >> can neutralize environmental influences and stop having to give
> >> >> >> theses
> >> >> >> tests special treatment.
> >> >> >>
> >> >> >> --
> >> >> >> Barak Korren
> >> >> >> bkor...@redhat.com
> >> >> >> RHEV-CI Team
> >> >> ___
> >> >> Devel mailing list
> >> >> Devel@ovirt.org
> >> >> http://lists.ovirt.org/mailman/listinfo/devel
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Eyal Edri
> >> > Associate Manager
> >> > RHEV DevOps
> >> > EMEA ENG Virtualization R
> >> > Red Hat Israel
> >> >
> >> > phone: +972-9-7692018
> >> > irc: eedri (on #tlv #rhev-dev #rhev-integ)
> >
> >
> >
> >
> > --
> > Eyal Edri
> > Associate Manager
> > RHEV DevOps
> > EMEA ENG Virtualization R
> > Red Hat Israel
> >
> > phone: +972-9-7692018
> > irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Failing MacPoolDaoTests on master

[Roman Mohr]

On Tue, May 31, 2016 at 11:21 AM, Eyal Edri  wrote:
> they only run on changes in :
>
> **/backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/businessentities/**
> **sql
> **/backend/manager/modules/dal/**
>

So where are the jobs for for https://gerrit.ovirt.org/#/c/58328/ for
instance? They should have been triggered, right?

> excluding file
> **/backend/manager/modules/dal/src/main/resources/bundles/**
>
> On Tue, May 31, 2016 at 12:15 PM, Roman Mohr  wrote:
>>
>> On Tue, May 31, 2016 at 11:12 AM, Eyal Edri  wrote:
>> > the dao tests 4.0 are on the new jenkins and they are running:
>> >
>> > http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_merged/
>> > http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_created/
>> >
>>
>> Am I missing somehting here? From my perspective it looks like they
>> are never triggered.
>>
>> > the old one in old jenkins should be deleted.
>> >
>> > On Tue, May 31, 2016 at 11:57 AM, Roman Mohr  wrote:
>> >>
>> >> On Tue, May 31, 2016 at 10:49 AM, Roman Mohr  wrote:
>> >> > On Tue, May 31, 2016 at 10:35 AM, Barak Korren 
>> >> > wrote:
>> >> >>> That seems to be another issue. When building locally and on travis
>> >> >>> we
>> >> >>> have failing dao tests, not missing libraries.
>> >> >>>
>> >> >>> Further, on jenkins it seems like we are not running the DAO tests
>> >> >>> since 26th of May.
>> >> >>> Wrote a mail to infra list regarding that about an hour ago.
>> >> >>
>> >> >> Those are still running on the old Jenkins, we only created them on
>> >> >> the new one for the new 4.0 branch.
>> >> >> http://jenkins-old.ovirt.org/search/?q=dao
>> >> >
>> >> > Ok, the failing tests on merged master patches are there.
>> >> > But we are not running tests on gerrit patches currently:
>> >> >
>> >> >
>> >> > http://jenkins-old.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_merged/
>> >> >
>> >> > Were they disabled deliberately?
>> >> >
>> >>
>> >> Oh that was the wrong job. So they are enabled:
>> >>
>> >>
>> >>
>> >> http://jenkins-old.ovirt.org/job/ovirt-engine_master_dao-unit-tests_created/
>> >>
>> >> So maybe the issue is that the CI tests from old and new jenkins are
>> >> overwriting their pluses and minuses?
>> >>
>> >> >>
>> >> >> We are working on moving these tests into check_patch.sh so that we
>> >> >> can neutralize environmental influences and stop having to give
>> >> >> theses
>> >> >> tests special treatment.
>> >> >>
>> >> >> --
>> >> >> Barak Korren
>> >> >> bkor...@redhat.com
>> >> >> RHEV-CI Team
>> >> ___
>> >> Devel mailing list
>> >> Devel@ovirt.org
>> >> http://lists.ovirt.org/mailman/listinfo/devel
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Eyal Edri
>> > Associate Manager
>> > RHEV DevOps
>> > EMEA ENG Virtualization R
>> > Red Hat Israel
>> >
>> > phone: +972-9-7692018
>> > irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
>
>
>
> --
> Eyal Edri
> Associate Manager
> RHEV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
>
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] dao tests status in CI

[Eyal Edri]

FYI,

All ovirt-engine dao tests (3.6,4.0,master) were moved to new jenkins and
the ones in the old one were disabled.

The jobs are still running in "old" mode and not yamelized.
Works is being done now to convert them to run in standard CI mode, under
mock which should add much more stability to flexibility to them for any
developer who would want to change/extend them.

-- 
Eyal Edri
Associate Manager
RHEV DevOps
EMEA ENG Virtualization R
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Failing MacPoolDaoTests on master

[Roman Mohr]

On Tue, May 31, 2016 at 11:12 AM, Eyal Edri  wrote:
> the dao tests 4.0 are on the new jenkins and they are running:
>
> http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_merged/
> http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_created/
>

Am I missing somehting here? From my perspective it looks like they
are never triggered.

> the old one in old jenkins should be deleted.
>
> On Tue, May 31, 2016 at 11:57 AM, Roman Mohr  wrote:
>>
>> On Tue, May 31, 2016 at 10:49 AM, Roman Mohr  wrote:
>> > On Tue, May 31, 2016 at 10:35 AM, Barak Korren 
>> > wrote:
>> >>> That seems to be another issue. When building locally and on travis we
>> >>> have failing dao tests, not missing libraries.
>> >>>
>> >>> Further, on jenkins it seems like we are not running the DAO tests
>> >>> since 26th of May.
>> >>> Wrote a mail to infra list regarding that about an hour ago.
>> >>
>> >> Those are still running on the old Jenkins, we only created them on
>> >> the new one for the new 4.0 branch.
>> >> http://jenkins-old.ovirt.org/search/?q=dao
>> >
>> > Ok, the failing tests on merged master patches are there.
>> > But we are not running tests on gerrit patches currently:
>> >
>> > http://jenkins-old.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_merged/
>> >
>> > Were they disabled deliberately?
>> >
>>
>> Oh that was the wrong job. So they are enabled:
>>
>>
>> http://jenkins-old.ovirt.org/job/ovirt-engine_master_dao-unit-tests_created/
>>
>> So maybe the issue is that the CI tests from old and new jenkins are
>> overwriting their pluses and minuses?
>>
>> >>
>> >> We are working on moving these tests into check_patch.sh so that we
>> >> can neutralize environmental influences and stop having to give theses
>> >> tests special treatment.
>> >>
>> >> --
>> >> Barak Korren
>> >> bkor...@redhat.com
>> >> RHEV-CI Team
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>
>
>
> --
> Eyal Edri
> Associate Manager
> RHEV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
>
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Failing MacPoolDaoTests on master

[Eyal Edri]

the dao tests 4.0 are on the new jenkins and they are running:

http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_merged/
http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_created/

the old one in old jenkins should be deleted.

On Tue, May 31, 2016 at 11:57 AM, Roman Mohr  wrote:

> On Tue, May 31, 2016 at 10:49 AM, Roman Mohr  wrote:
> > On Tue, May 31, 2016 at 10:35 AM, Barak Korren 
> wrote:
> >>> That seems to be another issue. When building locally and on travis we
> >>> have failing dao tests, not missing libraries.
> >>>
> >>> Further, on jenkins it seems like we are not running the DAO tests
> >>> since 26th of May.
> >>> Wrote a mail to infra list regarding that about an hour ago.
> >>
> >> Those are still running on the old Jenkins, we only created them on
> >> the new one for the new 4.0 branch.
> >> http://jenkins-old.ovirt.org/search/?q=dao
> >
> > Ok, the failing tests on merged master patches are there.
> > But we are not running tests on gerrit patches currently:
> >
> > http://jenkins-old.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_merged/
> >
> > Were they disabled deliberately?
> >
>
> Oh that was the wrong job. So they are enabled:
>
>
> http://jenkins-old.ovirt.org/job/ovirt-engine_master_dao-unit-tests_created/
>
> So maybe the issue is that the CI tests from old and new jenkins are
> overwriting their pluses and minuses?
>
> >>
> >> We are working on moving these tests into check_patch.sh so that we
> >> can neutralize environmental influences and stop having to give theses
> >> tests special treatment.
> >>
> >> --
> >> Barak Korren
> >> bkor...@redhat.com
> >> RHEV-CI Team
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>


-- 
Eyal Edri
Associate Manager
RHEV DevOps
EMEA ENG Virtualization R
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Failing MacPoolDaoTests on master

[Roman Mohr]

On Tue, May 31, 2016 at 10:49 AM, Roman Mohr  wrote:
> On Tue, May 31, 2016 at 10:35 AM, Barak Korren  wrote:
>>> That seems to be another issue. When building locally and on travis we
>>> have failing dao tests, not missing libraries.
>>>
>>> Further, on jenkins it seems like we are not running the DAO tests
>>> since 26th of May.
>>> Wrote a mail to infra list regarding that about an hour ago.
>>
>> Those are still running on the old Jenkins, we only created them on
>> the new one for the new 4.0 branch.
>> http://jenkins-old.ovirt.org/search/?q=dao
>
> Ok, the failing tests on merged master patches are there.
> But we are not running tests on gerrit patches currently:
>
> http://jenkins-old.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_merged/
>
> Were they disabled deliberately?
>

Oh that was the wrong job. So they are enabled:

http://jenkins-old.ovirt.org/job/ovirt-engine_master_dao-unit-tests_created/

So maybe the issue is that the CI tests from old and new jenkins are
overwriting their pluses and minuses?

>>
>> We are working on moving these tests into check_patch.sh so that we
>> can neutralize environmental influences and stop having to give theses
>> tests special treatment.
>>
>> --
>> Barak Korren
>> bkor...@redhat.com
>> RHEV-CI Team
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Failing MacPoolDaoTests on master

[Roman Mohr]

On Tue, May 31, 2016 at 10:35 AM, Barak Korren  wrote:
>> That seems to be another issue. When building locally and on travis we
>> have failing dao tests, not missing libraries.
>>
>> Further, on jenkins it seems like we are not running the DAO tests
>> since 26th of May.
>> Wrote a mail to infra list regarding that about an hour ago.
>
> Those are still running on the old Jenkins, we only created them on
> the new one for the new 4.0 branch.
> http://jenkins-old.ovirt.org/search/?q=dao

Ok, the failing tests on merged master patches are there.
But we are not running tests on gerrit patches currently:

http://jenkins-old.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_merged/

Were they disabled deliberately?

>
> We are working on moving these tests into check_patch.sh so that we
> can neutralize environmental influences and stop having to give theses
> tests special treatment.
>
> --
> Barak Korren
> bkor...@redhat.com
> RHEV-CI Team
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Failing MacPoolDaoTests on master

[Barak Korren]

> That seems to be another issue. When building locally and on travis we
> have failing dao tests, not missing libraries.
>
> Further, on jenkins it seems like we are not running the DAO tests
> since 26th of May.
> Wrote a mail to infra list regarding that about an hour ago.

Those are still running on the old Jenkins, we only created them on
the new one for the new 4.0 branch.
http://jenkins-old.ovirt.org/search/?q=dao

We are working on moving these tests into check_patch.sh so that we
can neutralize environmental influences and stop having to give theses
tests special treatment.

-- 
Barak Korren
bkor...@redhat.com
RHEV-CI Team
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Failing MacPoolDaoTests on master

[Martin Mucha]

I do apologize, fix patches are done and should be merged soon ...

M.

- Original Message -
> On Tue, May 31, 2016 at 10:13 AM, Barak Korren  wrote:
> > On 31 May 2016 at 10:45, Roman Mohr  wrote:
> >> Hi,
> >>
> >> DAO tests are failing on master in
> >>
> >> org.ovirt.engine.core.dao.MacPoolDaoTest.
> >>
> >> Build logs are here:
> >> https://travis-ci.org/oVirt/ovirt-engine/builds/134082394
> >>
> > Or here:
> > http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_created/3/console
> >
> > It seems there is a vdsm-jsonrpc-java-client build missing?
> >
> That seems to be another issue. When building locally and on travis we
> have failing dao tests, not missing libraries.
> 
> Further, on jenkins it seems like we are not running the DAO tests
> since 26th of May.
> Wrote a mail to infra list regarding that about an hour ago.
> 
> > 07:13:31 [ERROR] Failed to execute goal on project
> > common-dependencies: Could not resolve dependencies for project
> > org.ovirt.engine.core.manager:common-dependencies:jar:4.0.0: Could not
> > find artifact
> > org.ovirt.vdsm-jsonrpc-java:vdsm-jsonrpc-java-client:jar:1.2.3
> > in ovirt-maven-repository
> > (http://artifactory.ovirt.org/artifactory/ovirt-mirror) -> [Help 1]
> > 07:13:31 [ERROR]
> >
> >
> > --
> > Barak Korren
> > bkor...@redhat.com
> > RHEV-CI Team
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Failing MacPoolDaoTests on master

[Roman Mohr]

On Tue, May 31, 2016 at 10:13 AM, Barak Korren  wrote:
> On 31 May 2016 at 10:45, Roman Mohr  wrote:
>> Hi,
>>
>> DAO tests are failing on master in
>>
>> org.ovirt.engine.core.dao.MacPoolDaoTest.
>>
>> Build logs are here: 
>> https://travis-ci.org/oVirt/ovirt-engine/builds/134082394
>>
> Or here:
> http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_created/3/console
>
> It seems there is a vdsm-jsonrpc-java-client build missing?
>
That seems to be another issue. When building locally and on travis we
have failing dao tests, not missing libraries.

Further, on jenkins it seems like we are not running the DAO tests
since 26th of May.
Wrote a mail to infra list regarding that about an hour ago.

> 07:13:31 [ERROR] Failed to execute goal on project
> common-dependencies: Could not resolve dependencies for project
> org.ovirt.engine.core.manager:common-dependencies:jar:4.0.0: Could not
> find artifact org.ovirt.vdsm-jsonrpc-java:vdsm-jsonrpc-java-client:jar:1.2.3
> in ovirt-maven-repository
> (http://artifactory.ovirt.org/artifactory/ovirt-mirror) -> [Help 1]
> 07:13:31 [ERROR]
>
>
> --
> Barak Korren
> bkor...@redhat.com
> RHEV-CI Team
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Failing MacPoolDaoTests on master

[Barak Korren]

On 31 May 2016 at 10:45, Roman Mohr  wrote:
> Hi,
>
> DAO tests are failing on master in
>
> org.ovirt.engine.core.dao.MacPoolDaoTest.
>
> Build logs are here: https://travis-ci.org/oVirt/ovirt-engine/builds/134082394
>
Or here:
http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_created/3/console

It seems there is a vdsm-jsonrpc-java-client build missing?

07:13:31 [ERROR] Failed to execute goal on project
common-dependencies: Could not resolve dependencies for project
org.ovirt.engine.core.manager:common-dependencies:jar:4.0.0: Could not
find artifact org.ovirt.vdsm-jsonrpc-java:vdsm-jsonrpc-java-client:jar:1.2.3
in ovirt-maven-repository
(http://artifactory.ovirt.org/artifactory/ovirt-mirror) -> [Help 1]
07:13:31 [ERROR]


-- 
Barak Korren
bkor...@redhat.com
RHEV-CI Team
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Failing MacPoolDaoTests on master

[Roman Mohr]

Hi,

DAO tests are failing on master in

org.ovirt.engine.core.dao.MacPoolDaoTest.

Build logs are here: https://travis-ci.org/oVirt/ovirt-engine/builds/134082394

Best Regards,
Roman
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [vdsm] what happens to ovirmgmt during new host deployment?

[Ondřej Svoboda]

Thank you Kai for describing you solution!

However, I think the ovirtmgmt network should be created automatically. 
I will forward this issue on.




Cheers, Ondra


On 31.5.2016 05:04, Kai Kang wrote:

Hi Ondra,

Thanks for your patience with my so many questions.

Finally I search a Redhat defect 
https://bugzilla.redhat.com/show_bug.cgi?id=1222566, and it seems 
caused by lacking of libvirt network "vdsm-ovirtmgmt". After I create 
the network by hook, then the host could be deployed successfully.


Hook files under /usr/lib64/vdsm/vdsm/hooks/before_vdsm_start:

vdsm-ovirtmgmt.xml:

vdsm-ovirtmgmt





20-setupDefaultNetwork:
#!/bin/sh

VIRSH=/usr/bin/virsh
SOURCEDIR=$(dirname $(readlink -f $0))
DEFAULTNET=vdsm-ovirtmgmt

if ! $VIRSH net-dumpxml $DEFAULTNET &>/dev/null; then
$VIRSH net-define $SOURCEDIR/vdsm-ovirtmgmt.xml
fi


Regards,
Kai

On Fri, May 27, 2016 at 6:53 PM, Ondřej Svoboda > wrote:


Kai,

please also take a look at /var/log/ovirt-engine/engine.log

VDSM stores the engine's request for capabilities in vdsm.log, and
logs Setup Networks actions in supervdsm.log.

I'll inspect logs you sent me privately. Can you please make the
engine logs available to the list?

Thanks,
Ondra

- Original Message -
> From: "Kai Kang" >
> To: devel@ovirt.org 
> Sent: Friday, May 27, 2016 11:34:38 AM
> Subject: [ovirt-devel] [vdsm] what happens to ovirmgmt during
new hostdeployment?
>
> Hi,
>
> I sent mails to ovirt-user maillist for help. But it seems there
is no useful
> info in vdsm.log and supervdsm.log. I want to debug the code and
so ask for
> help here.
>
> I am using ovirt 3.6.4.1 and vdsm 4.17.24. When deploy a new
host, bridge
> ovirtmgmt has been created with port eth0. But it fails with:
>
> Host dell12 does not comply with the cluster Default networks,
the following
> networks are missing on host: 'ovirtmgmt'
>
>
> I can make ovirtmgmt work by selecting the tab 'Hosts' -> node
name(dell12)
> -> subtab 'Network Interface', click 'Setup Host Networks', drag
ovirtmgmt
> to link with ethernet interface eth0.
>
> What engine did to bridge ovirtmgmt during new host deployment?
Just call
> "getVdsCaps" to check whether ovirtmgmt is ready or sent
setupNetwork
> command to configure ovirtmgmt? Which part of vdsm code should I
check
> please?
>
> Thanks a lot.
>
> --Kai
>
> ___
> Devel mailing list
> Devel@ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/devel




___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel