Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: ydary@redhat.com
IRC : ydary
Il 29/Mar/2016 20:12, "Nir Soffer" <nsoffer@redhat.com> ha scritto:
>
> On Tue, Mar 29, 2016 at 9:09 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
> >
> > Il 29/Mar/2016 20:02, "Nir Soffer" <nsoffer@redhat.com> ha scritto:
> >>
> >> 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?
> >
> > For which version is this proposal targeted? 4.1?
>
> This is not targeted to any version yet, but I would be happy if we can do this
> for next release.I don't see it fitting 4.0 scope but I agree it would be nice to have in 4.1.
>
> Nir
_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel