On Tue, Mar 29, 2016 at 9:08 PM, Adam Litke <[email protected]> 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 _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
