On Mon, Oct 8, 2018 at 3:41 PM Marcin Sobczyk <msobczyk@redhat.com> wrote:

Hi,

when I was working on BZ#1624306 it turned out, that even if I'd fix the help-printing code in vdsm-client, there's still a lot of inconsistencies in API's schema files.

After some investigation, I found that there's a code for reporting schema inconsistencies, but it's turned off because it bloats the logs. There's also a "strict" mode that raises an exception each time an inconsistency is found, but it's also off because there's so many of them.

I think that no one wants to maintain both: the actual code and schema files. My idea would be to make the schema derived from the code at build time as a long-term effort. Before we can do that though, we need to address the inconsistencies first.

The schema is supposed to be the specification and the code its implementation. Generating the schema from the code does not sound right to me.

https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:vdsm-api-schema-debug

This is a series of patches that helps fixing schema issues. What it does, is it adds a bunch of information from stack to vastly ease the process of fixing them. The logging level is also changed from 'WARNING' to 'DEBUG'. Here's an example of a logged entry:

Host.setKsmTune
With message: Required property pages_to_scan is not provided when calling Host.setKsmTune
With backtrace: [
        [
                "_verify_object_type",
                {
                        "call_arg_keys":[
                                "merge_across_nodes",
                                "run"
                        ],
                        "schema_type_name":"KsmTuneParams"
                }
        ],
        [
                "_verify_complex_type",
                {
                        "schema_type_type":"object"
                }
        ]
]

To make it work, a patch for OST's 'basic-master-suite' is on the way that switches 'schema.inconsistency' logger's logging level do 'DEBUG'. That way, we can find all reported errors in 'vdsm-schema-error.log' files.

Will we be able to detect the caller?