Re: [ovirt-devel] Vdsm api package

[Piotr Kliczewski]

Yaniv,

Work public interface definition is covered by [1].

Thanks,
Piotr


[1] https://bugzilla.redhat.com/1304990

On Thu, Apr 28, 2016 at 8:59 AM, Yaniv Dary  wrote:

> Do we have a RFE on this?
>
> 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: yd...@redhat.com
> IRC : ydary
>
>
> On Tue, Mar 29, 2016 at 9:33 PM, Sandro Bonazzola 
> wrote:
>
>>
>> Il 29/Mar/2016 20:12, "Nir Soffer"  ha scritto:
>> >
>> > On Tue, Mar 29, 2016 at 9:09 PM, Sandro Bonazzola 
>> wrote:
>> > >
>> > > Il 29/Mar/2016 20:02, "Nir Soffer"  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
>>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Vdsm api package

[Yaniv Dary]

Do we have a RFE on this?

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: yd...@redhat.com
IRC : ydary


On Tue, Mar 29, 2016 at 9:33 PM, Sandro Bonazzola 
wrote:

>
> Il 29/Mar/2016 20:12, "Nir Soffer"  ha scritto:
> >
> > On Tue, Mar 29, 2016 at 9:09 PM, Sandro Bonazzola 
> wrote:
> > >
> > > Il 29/Mar/2016 20:02, "Nir Soffer"  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
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Vdsm api package

[Sandro Bonazzola]

Il 29/Mar/2016 20:12, "Nir Soffer"  ha scritto:
>
> On Tue, Mar 29, 2016 at 9:09 PM, Sandro Bonazzola 
wrote:
> >
> > Il 29/Mar/2016 20:02, "Nir Soffer"  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

Re: [ovirt-devel] Vdsm api package

[Nir Soffer]

On Tue, Mar 29, 2016 at 9:08 PM, Adam Litke  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
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Vdsm api package

[Nir Soffer]

On Tue, Mar 29, 2016 at 9:09 PM, Sandro Bonazzola  wrote:
>
> Il 29/Mar/2016 20:02, "Nir Soffer"  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.

Nir
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Vdsm api package

[Sandro Bonazzola]

Il 29/Mar/2016 20:02, "Nir Soffer"  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?


>
> Nir
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Vdsm api package

[Adam Litke]

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?

--
Adam Litke
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel