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

[Piotr Kliczewski]

On Wed, May 18, 2016 at 1:33 PM, Vinzenz Feenstra <vfeenstr at redhat.com>
wrote:

>
> On May 18, 2016, at 1:31 PM, Piotr Kliczewski <pkliczew at redhat.com> wrote:
>
> Please see [1][2]. We are seeing build issues for f23 so the build
> failures are not related.
> I asked Gil from infra to take a look.
>
>
I have update from Gil:

<gshinar> rpm nightly failed today. The ioproces and python-ioprocess are
corrupted.
<pkliczew> ok
<gshinar> will see what's the status of the nightly. Sandro was working on
fixing that
<pkliczew> great, thank you!


> +1 :-)
>
>
> Thanks,
> Piotr
>
> [1] https://gerrit.ovirt.org/#/c/57618/
> [2] https://gerrit.ovirt.org/#/c/57623
>
> On Wed, May 18, 2016 at 1:29 PM, Vinzenz Feenstra <vfeenstr at redhat.com>
> wrote:
>
>>
>> On May 18, 2016, at 1:23 PM, Dan Kenigsberg <danken at redhat.com> wrote:
>>
>> On Tue, May 17, 2016 at 08:44:11AM +0200, 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.
>>
>> Thanks,
>> Piotr
>>
>> On Mon, May 16, 2016 at 10:09 PM, Nir Soffer <nsoffer at redhat.com> 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
>>
>>
>> I'm officially annoyed ;-)
>> we can stop report rxRate and txRate now, as engine-3.6 computes them on
>> its own.
>>
>> Marcin, can you drop them from the code and schema?
>>
>> 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
>>
>>
>> Piotr, how can we specify in the schema the very common type of "string
>> that happens to include only unsigned decimal number”?
>>
>>
>> I remember that we talked about that with Piotr and that the best
>> solution would be a custom type for that, so that it can be checked
>> e.g. struint and strint as types, that means that those are integers
>> (signed/unsigned however passed as string) (Due to historical XMLRPC
>> reasons)
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160518/50521eb2/attachment-0001.html>