[ovirt-devel] Vdsm api package

Nir Soffer nsoffer at redhat.com
Tue Mar 29 18:17:13 UTC 2016


On Tue, Mar 29, 2016 at 9:08 PM, Adam Litke <alitke at redhat.com> wrote:
> On 29/03/16 21:01 +0300, Nir Soffer wrote:
>>
>> Hi all,
>>
>> In the Vdsm call, we discussed a way to expose vdsm errors to its clients
>> (e.g, engine, hosted engine agent/setup).
>>
>> The idea is to have a vdsmapi package, holding:
>> - errors.py - all public errors
>> - events.py - all events sent by vdsm
>> - client.py - library for communicating with vdsm
>> - schema.py - the client will use this to autogenerate online help and
>> validate messages
>> - schema.yaml - we probably need several files (gluster, events, etc.)
>>
>> This will allow other projects talking with vdsm to do:
>>
>>    from vdsmapi import client, errors
>>    ...
>>    try:
>>        client.list(vmId="xxxyyy")
>>    except errors.NoSuchVM:
>>        ...
>>
>> (this is a fake example, the real api may be different)
>>
>> Engine can build-require vdsmapi, and generate java module with the
>> public errors from
>> vdsmapi/errors.py module, instead of keeping this hardcoded in engine,
>> and updating
>> it every time vdsm adds new public error.
>>
>> Vdsm will use this package when building response to clients.
>>
>> Edi was concerned about sharing the errors module, so maybe we need a
>> package:
>>
>> vdsmapi/
>>    errors/
>>        network.py
>>        virt.py
>>        storage.py
>>        gluster.py
>>
>> We can still expose all the errors via errors/__init__.py, so clients
>> do not have to care about
>> the area of the application the error come from.
>>
>> Thoughts?
>
>
> Seems like a fantastic idea.  Would engine builds of the master branch
> always fetch the errors module from vdsm's master branch or would
> there be some synchronization points?

I guess the synchronization points would be the version of the package you
are targeting. Engine master will requires vdsmapi-4.0-gitxxxyyy, and
engine 4.0 will
use vdsmapi-4.0 etc.

Nir



More information about the Devel mailing list