[Ovirt-devel] Ovirt QMF API Proposal

[Jeremy Katz]

On Wednesday, April 01 2009, David Lutterkort said:
> On Wed, 2009-04-01 at 16:44 -0400, Jeremy Katz 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.
> 
> Can you give examples of what in the API proposal worries you in that
> regard ? What the QMF API exposes isn't too different from what the REST
> API (would) expose.

All of the specifics around pools and the way that storage works today
seems pretty closely tied.  Since direction of virt mgmt vs cloud mgmt
are pretty different here, it's the thing that immediately jumps out.  
 
> > 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
> 
> The API is targetted at both - whether an 'ordinary' cloud user is
> allowed to do certain operations is a question of permissions.
> 
> Some of that complexity will/can be hidden with more targetted tools on
> top of the API, either in the form of a client library or the command
> line tools that I started writing a while ago, but never finished.

So rather than getting people to use QMF (which is going to be a
challenge in and of itself given its still relative obscurity), we're
going to try to push people to using more lirbaries, etc on top of it?
Which means that if I want to use it from $some_other_crack_language,
I'm either going to have to bind it or use the underlying QMF api that
we're not wanting people to use?  This feels backwards.

The exposed API should be what we're targeting people to use, not some
mid-layer that stems from how we've implemented the world

Jeremy