> On May 18, 2016, at 1:31 PM, Piotr Kliczewski <[email protected]> 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.
+1 :-) 

> 
> Thanks,
> Piotr
> 
> [1] https://gerrit.ovirt.org/#/c/57618/ <https://gerrit.ovirt.org/#/c/57618/>
> [2] https://gerrit.ovirt.org/#/c/57623 <https://gerrit.ovirt.org/#/c/57623>
> 
> On Wed, May 18, 2016 at 1:29 PM, Vinzenz Feenstra <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>> On May 18, 2016, at 1:23 PM, Dan Kenigsberg <[email protected] 
>> <mailto:[email protected]>> 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 <[email protected] 
>>> <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> http://lists.ovirt.org/mailman/listinfo/devel 
>> <http://lists.ovirt.org/mailman/listinfo/devel>
> 

_______________________________________________
Devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel

Reply via email to