[Ovirt-devel] Ovirt QMF API Proposal

[Scott Seago]

Jeremy Katz wrote:
> 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.  
>  
>   
It may be  that we need multiple API levels here, but tying it to 
(hardware and VM) pools and the current oVirt model is actually pretty 
deliberate here. We _want_ to expose all of the oVirt-specific actions 
here so that everything that the UI does can be performed by other means 
as well -- cmdline, other mgmt apps, etc. If we don't expose 
ovirt-specific bits, then we can't perform oVirt-specific actions.

Having a non-oVirt-specific mid-level API would be useful too, but 
that's not my understanding of what we're doing here.

Scott