<p dir="ltr"><br>
Il 29/Mar/2016 20:02, "Nir Soffer" <<a href="mailto:nsoffer@redhat.com">nsoffer@redhat.com</a>> ha scritto:<br>
><br>
> Hi all,<br>
><br>
> In the Vdsm call, we discussed a way to expose vdsm errors to its clients<br>
> (e.g, engine, hosted engine agent/setup).<br>
><br>
> The idea is to have a vdsmapi package, holding:<br>
> - errors.py - all public errors<br>
> - events.py - all events sent by vdsm<br>
> - client.py - library for communicating with vdsm<br>
> - schema.py - the client will use this to autogenerate online help and<br>
> validate messages<br>
> - schema.yaml - we probably need several files (gluster, events, etc.)<br>
><br>
> This will allow other projects talking with vdsm to do:<br>
><br>
> from vdsmapi import client, errors<br>
> ...<br>
> try:<br>
> client.list(vmId="xxxyyy")<br>
> except errors.NoSuchVM:<br>
> ...<br>
><br>
> (this is a fake example, the real api may be different)<br>
><br>
> Engine can build-require vdsmapi, and generate java module with the<br>
> public errors from<br>
> vdsmapi/errors.py module, instead of keeping this hardcoded in engine,<br>
> and updating<br>
> it every time vdsm adds new public error.<br>
><br>
> Vdsm will use this package when building response to clients.<br>
><br>
> Edi was concerned about sharing the errors module, so maybe we need a package:<br>
><br>
> vdsmapi/<br>
> errors/<br>
> network.py<br>
> virt.py<br>
> storage.py<br>
> gluster.py<br>
><br>
> We can still expose all the errors via errors/__init__.py, so clients<br>
> do not have to care about<br>
> the area of the application the error come from.<br>
><br>
> Thoughts?</p>
<p dir="ltr">For which version is this proposal targeted? 4.1?<br><br><br></p>
<p dir="ltr">><br>
> Nir<br>
> _______________________________________________<br>
> Devel mailing list<br>
> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
> <a href="http://lists.ovirt.org/mailman/listinfo/devel">http://lists.ovirt.org/mailman/listinfo/devel</a><br>
</p>