[Ovirt-devel] Ovirt QMF API Proposal

[Ian Main]

On Wed, 1 Apr 2009 16:44:48 -0400
Jeremy Katz <katzj at redhat.com> wrote:

> On Tuesday, March 31 2009, Ian Main said:
> > Through much discussion it was decided that we would leverage the rails
> > models created for use in the WUI, and create an alternative way to
> > access these models, start tasks etc.  This will be integrated with the
> > current task management system (taskomatic) to produce a complete package.
> > 
> > The idea is to create a set of classes available via QMF as objects.
> > These classes would then be backed by either a mid-level API that
> > encompasses the models, or by active record models directly.  Any changes
> > made to these records outside of the API (eg by the WUI) would require
> > notification of changes to taskomatic.
> 
> So, by integrating deeply like this, how much is going to be tied to underlying 
> implementation details that (may|might|will) change in the future?  From
> looking through it, it seems very tightly tied which given the many
> unanswered questions, is at least of some concern imho.

This was my concern as well.. by working with models directly we tie the
hands of the UI developers to an extent.  However I think they have a
good understanding of this and I do believe we are going to have a
mid-level API that both the UI and the QMF API will use.  I was
originally proposing that the UI be based on top of QMF as well to
provide a single API/entry point but there were concerns with
performance and type changes.

QMF lets you get a schema of the API as well, so it would be possible
to check for capabilities/versions via QMF itself.

Also, to a good extent, an API will always be dependent on some
implementation details.

> Also, who is the expected target user of this API?  Someone who is
> deploying guests within the cloud or someone who is managing the overall
> cloud?  As there's probably a different level of care for what are the
> important things to expose accordingly.  It looks more like the latter
> but with a mix of some of the former, but at a far more detailed level
> than a cloud user would need/want

Basically this just implements a portion of the existing ovirt
functionality.  Cloud is a work in progress at this point and I expect
we will develop the API in conjuction with the new features.  There is
nothing stopping us from creating a new 'make VM anywhere with xx GB
storage' method and having taskomatic handle all of that magically.

    Ian