[ovirt-devel] [oVirt 4.0 Localization Question #4] "Disk Containers Icon"

[Yuko Katabami]

Hi all,

Could anyone help us with the following question?

​​*File: *UI Common ApplicationConstants

*Resource ID: *containersIconDisk

*String: *Disk Containers Icon

*Question:* Is Container plural or should be singular with apostrophe s?
(i.e. Container's Icon)


Kind regards,


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

Re: [ovirt-devel] In-place sparsify support in VDSM

[Richard W.M. Jones]

On Tue, May 17, 2016 at 09:50:07PM +0300, Nir Soffer wrote:
> On Tue, May 17, 2016 at 7:14 PM, Shmuel Melamud  wrote:
> 
> > Hi!
> >
> > There is an RFE being implemented currently (
> > https://bugzilla.redhat.com/show_bug.cgi?id=734120) to use --inplace
> > option in virt-sparsify to sparsify a disk image in-place, without copying
> > it.
> >
> > The problem is that in-place sparsify works on NFS only starting from NFS
> > 4.2, while the copying implementation supposedly works with any storage.
> >
> > From my point of view, it is better to remove the old code and start with
> > the new code that uses --inplace and just add to document that one will
> > need NFS >= 4.2 for sparsify feature to work. Although the old
> > implementation exists, it is not used currently so there are no actual
> > users that may be affected by the change. If it will be a crying need to
> > use sparsify on older NFS or some other incompatible storage, we can add it
> > later on the base of the new code. The old code is far from ideal and we
> > will need to rewrite it in any case, and there is not sense to do this
> > without real need.
> >
> 
> Richard,
> 
> Currently vdsm is using:
> 
> virt-sparsify --tmp prebuilt:tmp_vol --format src_format --convert
> dst_format src_vol dst_vol

> (--format and --dst_format are optional)
> 
> tmp_vol, src_vol, and dst_vol can be either file on nfs/glusterfs/other
> posix shared filesystem,
> or an lv created on top of lun (iscsi/fc).
> 
> can you confirm this method works on all the storage types I mentioned? or
> this depends
> on the underlying storage server?

Copying mode requires that the dst_vol supports sparseness.  The most
common case where this would *not* be true is partitions on local hard
disks.  You can't make a partition and/or local hard disk sparse.

However all of the ones you've mentioned above support sparseness, so
you should be good.

*If* you were using --inplace only, you could nuke the --tmp option,
and indeed all the code associated with "prebuilt" qcow2 files for
scratch space.

That's because --inplace mode uses hardly any temporary storage, so
you can just have it use regular /var/tmp or $TMPDIR.

However ...
 
> The new inplace method is much nicer, but something that works only on
> latest NFS version
> is not useful for our most important users, using block storage.

... it's a shame, but yes.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] In-place sparsify support in VDSM

[Nir Soffer]

On Tue, May 17, 2016 at 7:14 PM, Shmuel Melamud  wrote:

> Hi!
>
> There is an RFE being implemented currently (
> https://bugzilla.redhat.com/show_bug.cgi?id=734120) to use --inplace
> option in virt-sparsify to sparsify a disk image in-place, without copying
> it.
>
> The problem is that in-place sparsify works on NFS only starting from NFS
> 4.2, while the copying implementation supposedly works with any storage.
>
> From my point of view, it is better to remove the old code and start with
> the new code that uses --inplace and just add to document that one will
> need NFS >= 4.2 for sparsify feature to work. Although the old
> implementation exists, it is not used currently so there are no actual
> users that may be affected by the change. If it will be a crying need to
> use sparsify on older NFS or some other incompatible storage, we can add it
> later on the base of the new code. The old code is far from ideal and we
> will need to rewrite it in any case, and there is not sense to do this
> without real need.
>

Richard,

Currently vdsm is using:

virt-sparsify --tmp prebuilt:tmp_vol --format src_format --convert
dst_format src_vol dst_vol

(--format and --dst_format are optional)

tmp_vol, src_vol, and dst_vol can be either file on nfs/glusterfs/other
posix shared filesystem,
or an lv created on top of lun (iscsi/fc).

can you confirm this method works on all the storage types I mentioned? or
this depends
on the underlying storage server?

The new inplace method is much nicer, but something that works only on
latest NFS version
is not useful for our most important users, using block storage.

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

Re: [ovirt-devel] oVirt 4.0.0 beta build planned

[Eyal Edri]

Please try to use any physical host marked with 'physical' label to build
heavy duty builds like ovirt-engine.
It shouldn't have any queue, as these are RSVP for Lago runs only.

On Tue, May 17, 2016 at 7:06 PM, Sandro Bonazzola 
wrote:

> Fyi oVirt developers,
>
>
> Just a reminder that an oVirt build is planned for tomorrow, Wednesday
> 11:00 AM TLV time (10:00 AM CET).
>
> Taking into consideration the time it takes for Jenkins to run a full CI
> everything need to be backported by today, Tuesday 11PM TLV time.
>
> Please make sure to mark as verified and CR +2 your patches so it will be
> ready for merging Wednesday morning.
>
> Thanks.
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
>
> ___
> 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

[ovirt-devel] In-place sparsify support in VDSM

[Shmuel Melamud]

Hi!

There is an RFE being implemented currently (
https://bugzilla.redhat.com/show_bug.cgi?id=734120) to use --inplace option
in virt-sparsify to sparsify a disk image in-place, without copying it.

The problem is that in-place sparsify works on NFS only starting from NFS
4.2, while the copying implementation supposedly works with any storage.

>From my point of view, it is better to remove the old code and start with
the new code that uses --inplace and just add to document that one will
need NFS >= 4.2 for sparsify feature to work. Although the old
implementation exists, it is not used currently so there are no actual
users that may be affected by the change. If it will be a crying need to
use sparsify on older NFS or some other incompatible storage, we can add it
later on the base of the new code. The old code is far from ideal and we
will need to rewrite it in any case, and there is not sense to do this
without real need.

What do you think?

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

[ovirt-devel] oVirt 4.0.0 beta build planned

[Sandro Bonazzola]

Fyi oVirt developers,


Just a reminder that an oVirt build is planned for tomorrow, Wednesday
11:00 AM TLV time (10:00 AM CET).

Taking into consideration the time it takes for Jenkins to run a full CI
everything need to be backported by today, Tuesday 11PM TLV time.

Please make sure to mark as verified and CR +2 your patches so it will be
ready for merging Wednesday morning.

Thanks.

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Vdsm call 17/5/2016 summary

[Yaniv Kaul]

On Tue, May 17, 2016 at 5:44 PM, Yaniv Bronheim  wrote:

> *VDSM call 17/5/2016*
>
> mzamzal, mpolednik, edwardh, danken, ybronhei, igoihman, nsoffer, pkliczew
>
> *mzamza* -
> * Working on debian support to run vms. still experimental. Milan will
> send elaborated mail about it.
>
> *pkliczew* -
> * We replaced the json with yaml schema, now when engine sends not well
> defined request we warn it in vdsm.log. this leaded to many warn logs which
> makes it harder to follow issues. we currently look for solution there.
> * Additional to that, it exposed issue with gluster cli that we currently
> investigate.
>
> *igoihman* -
> * We merged a patch that from now on every test that we add to the system
> it needs to pass python3 unless you add it to a blacklist. This is another
> way to remind developers to be compatible with python3 (this part of
> accelerating our move to python3 as for now python-blivert which gluster
> uses won't be available in f25 and above for python2 - so we must support
> python3 to work over later fedora versions).
> * We merged tox support which replaces the need for pep8 and pyflakes.
> This allows to align with specific versions of pep8 and pyflakes. I updated
> vdsm-developers wiki patch about that.
>
> *nsoffer* -
> * Working on discard fixes - allows to reuse wiped storage.
> * Supporting flash in mount points.
> * Fix circular dependencies in storage server tests.
> * Introduced Image uploader - daemon (ovirt-imageio) that allows to upload
> (later download) images directly from engine by http from hosts
> * Proposed to have vdsm blog that talks about new plans such as the debian
> support.
>

We can blog every other week or so, or on a monthly basis, on ovirt.org
blog about this. The blog is not strictly for users.
I'd be happy to see such content.
Y.


>
> *mpolednik *-
> * Working on fixing the api to changeCD (
> https://gerrit.ovirt.org/#/c/56805/).
>
> *danken *-
> * openvswitch support - still work in process. we might get it async to
> 4.0.
>
> *ybronhei *-
> * Managed to push forward host package refactoring and will publish soon
> the metric collection plans
>
> Thanks for participating. Feel free to comment
>
> --
> *Yaniv Bronhaim.*
>
> ___
> 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] [vdsm] Another network test failing

[Adam Litke]

On 17/05/16 09:45 +0300, Dan Kenigsberg wrote:

On Tue, May 17, 2016 at 01:10:19AM +0300, Nir Soffer wrote:

On Mon, May 16, 2016 at 4:52 PM, Adam Litke  wrote:
> On 15/05/16 15:10 +0300, Dan Kenigsberg wrote:
>>
>> On Sun, May 15, 2016 at 10:33:30AM +0300, Edward Haas wrote:
>>>
>>> On Tue, May 10, 2016 at 8:19 PM, Adam Litke  wrote:
>>>
>>> > On 10/05/16 18:08 +0300, Dan Kenigsberg wrote:
>>> >
>>> >> On Mon, May 09, 2016 at 02:48:43PM -0400, Adam Litke wrote:
>>> >>
>>> >>> When running make check on my local system I often (but not always)
>>> >>> get the following error:
>>> >>>
>>> >>
>>> >> Do you have any clue related to when this happens? (your pwd,
>>> >> pythonpath)
>>> >>
>>> >
>>> > Maybe it's a side effect of the way nose loads and runs tests?
>>> >
>>> > Did it begin with the recent move of netinfo under vdsm.network?
>>> >> https://gerrit.ovirt.org/56713 (CommitDate: Thu May 5) or did you see
>>> >> it
>>> >> earlier?
>>> >>
>>> >
>>> > That's possible.  It only started happening recently.  It seems to
>>> > fail only when run under 'make check' but not when run via
>>> > ./run_tests_local.sh.
>>>
>>>
>>> Is it possible that on the same machine you have installed an older vdsm
>>> version
>>> and it somehow conflicts? (resolving vdsm from the site-packages instead
>>> from
>>> the local workspace)
>>
>>
>> Or maybe you have *.pyc from an older directory structure left in your
>> working directory?
>
>
> I think this was the issue.  Removing *.pyc from the source tree fixed
> it.  Thanks!

git clean -dxf is very useful from time to time


Yet very dangerous in another times (yes, once upon a time I had the
only copy of a helper script hiding within the leafs of a git tree)



Been there too.  Maybe it's time we fix 'make clean'.

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

Re: [ovirt-devel] gerrit.ovirt.org projects

[Vojtech Szocs]

- Original Message -
> From: "Shlomo Ben David" 
> To: devel@ovirt.org
> Sent: Tuesday, May 17, 2016 1:49:30 PM
> Subject: [ovirt-devel] gerrit.ovirt.org projects
> 
> Hi,
> 
> I have a question about projects on gerrit.ovirt.org .
> I'm working on cleaning up the gerrit.ovirt.org and updating the replication
> process to github, I've noticed that the projects below weren't updated > ~6
> months.
> 
> Do you know which of the below projects is still relevant for replication
> (sync to github)?
> 
> ovirt-register
> test
> chrooter
> gluster-nagios-monitoring
> ovirt-container-node
> ovirt-container-engine
> ovirt-engine-sdk-js

The `ovirt-engine-sdk-js` was meant to contain JavaScript SDK
for working with Engine REST API. It's currently empty, we plan
to merge some (older) stuff there for future reference.

For now, there's no need to replicate this project to GitHub.

> vdsm-arch-dependencies
> ovirt-node-dbus-backend
> samples-portals
> jasperreports-server-rpm
> ovirt-node-tests
> ovirt-engine-sdk-tests
> Node
> ovirt-tools-common-python
> mediawiki-example
> 
> 
> Thanks in advanced,
> 
> Shlomi Ben-David | Software Engineer | Red Hat ISRAEL
> Phone: +972-54-8008858
> IRC: sbendavi
> 
> OPEN SOURCE - 1 4 011 && 011 4 1
> 
> ___
> 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] gerrit.ovirt.org projects

[Shlomo Ben David]

Hi,

I have a question about projects on gerrit.ovirt.org.
I'm working on cleaning up the gerrit.ovirt.org and updating the
replication process to github, I've noticed that the projects below weren't
updated > ~6 months.

Do you know which of the below projects is still relevant for replication
(sync to github)?

ovirt-register
test
chrooter
gluster-nagios-monitoring
ovirt-container-node
ovirt-container-engine
ovirt-engine-sdk-js
vdsm-arch-dependencies
ovirt-node-dbus-backend
samples-portals
jasperreports-server-rpm
ovirt-node-tests
ovirt-engine-sdk-tests
Node
ovirt-tools-common-python
mediawiki-example


Thanks in advanced,

Shlomi Ben-David | Software Engineer | Red Hat ISRAEL
Phone: +972-54-8008858
IRC: sbendavi

OPEN SOURCE - 1 4 011 && 011 4 1
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] Excessive warnings in vdsm log

[Nir Soffer]

The best way is to use warnings.warn instead of logging.warning - we
already using this for similar stuf, and we have a configuration option ti
enabke the warnings in the logs.

Nir
בתאריך 17 במאי 2016 11:33 לפנה״צ,‏ "Martin Sivak"  כתב:

Can't we just configure the logging level for the specific logger?
That is why we use them. Keep the logging, but change the default for
schemaapi to ERROR for now.

Martin

On Tue, May 17, 2016 at 8:47 AM, Yaniv Kaul  wrote:
>
>
> On Tue, May 17, 2016 at 9:44 AM, Piotr Kliczewski 
> wrote:
>>
>> Nir,
>>
>> The warnings were added to annoy people so we could keep the schema align
>> with the code.
>> I think that we should use this opportunity to push fixes instead of
>> disabling it.
>
>
> I agree to the end goal, but I don't think this specific method would
work.
> I much rather we'll do a concentrated effort to drastically reduce those -
> and I don't think right now is the best time for it (a bit late for 4.0)
> Y.
>
>>
>> Thanks,
>> Piotr
>>
>> On Mon, May 16, 2016 at 10:09 PM, Nir Soffer  wrote:
>>>
>>> Hi all,
>>>
>>> Since data verification patches were merged, vdsm logs is spammed with
>>> useless warnings (see bellow).
>>>
>>> This spam make it harder to debug vdsm.
>>>
>>> Please add configuration variable to enable this warnings, and make
>>> them disabled by default.
>>>
>>> Thanks,
>>> Nir
>>>
>>> 
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,719::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Following parameters ['ksmMergeAcrossNodes', 'haStats'] were not
>>> recognized
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter cpuUserVdsmd is not float type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter rxRate is not float type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter cpuLoad is not float type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter memUsed is not uint type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter cpuIdle is not float type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter txRate is not float type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter txDropped is not uint type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter elapsedTime is not uint type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter netConfigDirty is not boolean type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter rxErrors is not uint type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter rxRate is not float type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,722::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter rx is not uint type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,722::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter txDropped is not uint type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,722::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter txErrors is not uint type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,722::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter txRate is not float type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,722::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter speed is not uint type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,723::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter tx is not uint type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,723::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter rxDropped is not uint type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,723::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter rxErrors is not uint type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,723::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter rxRate is not float type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,723::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter rx is not uint type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 

Re: [ovirt-devel] FATAL: Operation aborted, found duplicate version: 04000640

[Martin Perina]

Hi,

it have already been fixed in https://gerrit.ovirt.org/57531

Martin


On Tue, May 17, 2016 at 11:11 AM, Yedidyah Bar David 
wrote:

> Hi,
>
> Please handle.
>
> Found on jenkins [1].
>
> [1]
> http://jenkins.ovirt.org/job/ovirt-engine_master_upgrade-from-master_el7_merged/257/
>
> Thanks,
> --
> Didi
> ___
> 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] FATAL: Operation aborted, found duplicate version: 04000640

[Yedidyah Bar David]

Hi,

Please handle.

Found on jenkins [1].

[1] 
http://jenkins.ovirt.org/job/ovirt-engine_master_upgrade-from-master_el7_merged/257/

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

Re: [ovirt-devel] [VDSM] Excessive warnings in vdsm log

[Yaniv Kaul]

On Tue, May 17, 2016 at 9:44 AM, Piotr Kliczewski 
wrote:

> Nir,
>
> The warnings were added to annoy people so we could keep the schema align
> with the code.
> I think that we should use this opportunity to push fixes instead of
> disabling it.
>

I agree to the end goal, but I don't think this specific method would work.
I much rather we'll do a concentrated effort to drastically reduce those -
and I don't think right now is the best time for it (a bit late for 4.0)
Y.


> Thanks,
> Piotr
>
> On Mon, May 16, 2016 at 10:09 PM, Nir Soffer  wrote:
>
>> Hi all,
>>
>> Since data verification patches were merged, vdsm logs is spammed with
>> useless warnings (see bellow).
>>
>> This spam make it harder to debug vdsm.
>>
>> Please add configuration variable to enable this warnings, and make
>> them disabled by default.
>>
>> Thanks,
>> Nir
>>
>> 
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,719::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Following parameters ['ksmMergeAcrossNodes', 'haStats'] were not
>> recognized
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter cpuUserVdsmd is not float type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter rxRate is not float type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter cpuLoad is not float type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter memUsed is not uint type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter cpuIdle is not float type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter txRate is not float type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter txDropped is not uint type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter elapsedTime is not uint type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter netConfigDirty is not boolean type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter rxErrors is not uint type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter rxRate is not float type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,722::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter rx is not uint type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,722::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter txDropped is not uint type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,722::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter txErrors is not uint type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,722::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter txRate is not float type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,722::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter speed is not uint type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,723::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter tx is not uint type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,723::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter rxDropped is not uint type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,723::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter rxErrors is not uint type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,723::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter rxRate is not float type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,723::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter rx is not uint type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,723::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter txDropped is not uint type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,724::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter txErrors is not uint type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,724::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter txRate is not float type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,724::schemaapi::140::SchemaCache::(_report_inconsistency)
>> Parameter speed is not uint type
>> jsonrpc.Executor/0::WARNING::2016-05-16
>> 23:05:21,724::schemaapi::140::SchemaCache::(_report_inconsistency)

Re: [ovirt-devel] [vdsm] Another network test failing

[Dan Kenigsberg]

On Tue, May 17, 2016 at 01:10:19AM +0300, Nir Soffer wrote:
> On Mon, May 16, 2016 at 4:52 PM, Adam Litke  wrote:
> > On 15/05/16 15:10 +0300, Dan Kenigsberg wrote:
> >>
> >> On Sun, May 15, 2016 at 10:33:30AM +0300, Edward Haas wrote:
> >>>
> >>> On Tue, May 10, 2016 at 8:19 PM, Adam Litke  wrote:
> >>>
> >>> > On 10/05/16 18:08 +0300, Dan Kenigsberg wrote:
> >>> >
> >>> >> On Mon, May 09, 2016 at 02:48:43PM -0400, Adam Litke wrote:
> >>> >>
> >>> >>> When running make check on my local system I often (but not always)
> >>> >>> get the following error:
> >>> >>>
> >>> >>
> >>> >> Do you have any clue related to when this happens? (your pwd,
> >>> >> pythonpath)
> >>> >>
> >>> >
> >>> > Maybe it's a side effect of the way nose loads and runs tests?
> >>> >
> >>> > Did it begin with the recent move of netinfo under vdsm.network?
> >>> >> https://gerrit.ovirt.org/56713 (CommitDate: Thu May 5) or did you see
> >>> >> it
> >>> >> earlier?
> >>> >>
> >>> >
> >>> > That's possible.  It only started happening recently.  It seems to
> >>> > fail only when run under 'make check' but not when run via
> >>> > ./run_tests_local.sh.
> >>>
> >>>
> >>> Is it possible that on the same machine you have installed an older vdsm
> >>> version
> >>> and it somehow conflicts? (resolving vdsm from the site-packages instead
> >>> from
> >>> the local workspace)
> >>
> >>
> >> Or maybe you have *.pyc from an older directory structure left in your
> >> working directory?
> >
> >
> > I think this was the issue.  Removing *.pyc from the source tree fixed
> > it.  Thanks!
> 
> git clean -dxf is very useful from time to time

Yet very dangerous in another times (yes, once upon a time I had the
only copy of a helper script hiding within the leafs of a git tree)
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] Excessive warnings in vdsm log

[Piotr Kliczewski]

Nir,

The warnings were added to annoy people so we could keep the schema align
with the code.
I think that we should use this opportunity to push fixes instead of
disabling it.

Thanks,
Piotr

On Mon, May 16, 2016 at 10:09 PM, Nir Soffer  wrote:

> Hi all,
>
> Since data verification patches were merged, vdsm logs is spammed with
> useless warnings (see bellow).
>
> This spam make it harder to debug vdsm.
>
> Please add configuration variable to enable this warnings, and make
> them disabled by default.
>
> Thanks,
> Nir
>
> 
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,719::schemaapi::140::SchemaCache::(_report_inconsistency)
> Following parameters ['ksmMergeAcrossNodes', 'haStats'] were not
> recognized
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter cpuUserVdsmd is not float type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter rxRate is not float type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter cpuLoad is not float type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter memUsed is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter cpuIdle is not float type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter txRate is not float type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter txDropped is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter elapsedTime is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter netConfigDirty is not boolean type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter rxErrors is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter rxRate is not float type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,722::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter rx is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,722::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter txDropped is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,722::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter txErrors is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,722::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter txRate is not float type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,722::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter speed is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,723::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter tx is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,723::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter rxDropped is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,723::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter rxErrors is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,723::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter rxRate is not float type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,723::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter rx is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,723::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter txDropped is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,724::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter txErrors is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,724::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter txRate is not float type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,724::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter speed is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,724::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter tx is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,724::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter rxDropped is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 23:05:21,725::schemaapi::140::SchemaCache::(_report_inconsistency)
> Parameter rxErrors is not uint type
> jsonrpc.Executor/0::WARNING::2016-05-16
> 

Re: [ovirt-devel] Unable to login to gerrit.ovirt.org with Google OAuth2 (gerrit-oauth-provider plugin)

[Barak Korren]

Should be ok now.
Please refer infrastructure issues to in...@ovirt.org next time.

On 17 May 2016 at 09:24, Ramesh Nachimuthu  wrote:
> Hi,
>
>  I am not able to login to gerrit.ovirt.org using Google OAuth2 
> (gerrit-oauth-provider plugin). It says 'Server Error'. Anyone else facing 
> the same issue?
>
>
> Regards,
> Ramesh
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel



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

[ovirt-devel] Unable to login to gerrit.ovirt.org with Google OAuth2 (gerrit-oauth-provider plugin)

[Ramesh Nachimuthu]

Hi,

 I am not able to login to gerrit.ovirt.org using Google OAuth2 
(gerrit-oauth-provider plugin). It says 'Server Error'. Anyone else facing the 
same issue?


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