To the question of "What blocks us using the current VDSM API?".

The main issue is supportability, This is also why it's the first point of 
The current API has no supportability guidelines and there is no way we could 
support it for the long run.

Further more the current API, apart from being outdated is highly 
engine-specific. A lot of the decisions are related to VDSM having to slow down 
development to accommodate the slower pace of movement of the giant the is the 
This means, for example having confusing verbs and argument names (eg. destroy, 
and iscsi portals). Having redundant steps in the setup of things (eg. storage 
domain creation). Arbitrary limitations (eg. storage pools, iso\export 
domains), etc.

In order to give a well supported API, we need to think about what we expose 
and how we expose it. Every verb should be thoroughly examined.

This was not the case when the original API was created because, as I already 
noted, it was built to a case where the supported API is at the Engine level 
and not the VDSM level. This made creating\removing verbs a lot quicker and 
less "expensive", accepting things we knew were not ideal with the knowledge we 
can change them the next version. This cannot be the case with a supported 
public API.

----- Original Message -----
> From: "Deepak C Shetty" <>
> To: "Saggi Mizrahi" <>
> Cc: "VDSM Project Development" <>, "Anthony 
> Liguori" <>
> Sent: Monday, June 18, 2012 1:35:21 PM
> Subject: Re: [vdsm] [virt-node] VDSM as a general purpose virt host manager
> On 06/18/2012 08:32 PM, Saggi Mizrahi wrote:
> > I would like to put on to the table for descussion the growing need
> > for a way
> > to more easily reuse of the functionality of VDSM in order to
> > service projects
> > other than Ovirt-Engine.
> >
> > Originally VDSM was created as a proprietary agent for the sole
> > purpose of
> > serving the then proprietary version of what is known as
> > ovirt-engine. Red Hat,
> > after acquiring the technology, pressed on with it's commitment to
> > open source
> > ideals and released the code. But just releasing code into the wild
> > doesn't
> > build a community or makes a project successful. Further more when
> > building
> > open source software you should aspire to build reusable components
> > instead of
> > monolithic stacks.
> >
> Can you list issues that block tools (other than ovirt-engine) in
> using
> VDSM ?
> That will help provide more clarity and scope of work described here.
> I understand the lack of REST API, which is where Adam's work comes
> in.
> With REST API support for vdsm, other tools can integrate upwardly
> with
> VDSM and exploit it. What else ? How does the current API layer
> design/implementation inhibit tools other than ovirt-engine to use
> VDSM  ?
> > We would like to expose a stable, documented, well supported API.
> > This gives
> > us a chance to rethink the VDSM API from the ground up. There is
> > already work
> > in progress of making the internal logic of VDSM separate enough
> > from the API
> > layer so we could continue feature development and bug fixing while
> > designing
> > the API of the future.
> >
> > In order to achieve this though we need to do several things:
> >     1. Declare API supportability guidelines
> >     2. Decide on an API transport (e.g. REST, ZMQ, AMQP)
> >     3. Make the API easily consumable (e.g. proper docs, example
> >     code, extending
> >        the API, etc)
> >     4. Implement the API itself
> >
> > All of these are dependent on one another and the permutations are
> > endless.
> > This is why I think we should try and work on each one separately.
> > All
> > discussions will be done openly on the mailing list and until the
> > final version
> > comes out nothing is set in stone.
> >
> > If you think you have anything to contribute to this process,
> > please do so
> > either by commenting on the discussions or by sending
> > code/docs/whatever
> > patches. Once the API solidifies it will be quite difficult to
> > change
> > fundamental things, so speak now or forever hold your peace. Note
> > that this is
> > just an introductory email. There will be a quick follow up email
> > to kick start
> > the discussions.
> > _______________________________________________
> > vdsm-devel mailing list
> >
> >
vdsm-devel mailing list

Reply via email to