[Ovirt-devel] Ovirt QMF API Proposal

Thomas von Steiger thomas.vonsteiger at bluewin.ch
Sat Apr 4 13:30:58 UTC 2009


On 03.04.2009, at 06:28, Ian Main wrote:

> 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

In a cloud, there are 1'000 - 500'000 virtual servers, virtual  
services, there are 100-50'000 baremetals.
There are xx TB of storage and memory and everything is connected over  
networks.
Each of them has information about itself, there are information about  
customers, application, capabilities, billing etc.
I think it's not possible for one framework to manage everthing.
There are massiv information in future between differend frameworks  
only for cloud management and this will be generate traffic.
Tomorrow, we need to create 1000 server before the coffee break, after  
the coffee break we can check them.
This are all small task they need to be done inside differend  
connected frameworks. This frameworks need to talk in common.
With QMF it's great, it's possible to have managment communication  
between this differend frameworks.

For example, we write a framework where we can manage baremetal's.
For this we need coordinate information about geographic, city,  
building, room, racks.
Finally in the rack, there are my baremetal.
For a logical UI we need to define everything from top/down before we  
can load a baremetal in a rack.
At this point where i click ok in my framewok for adding a city or  
building, it can send a message over qmf to all other necessary  
frameworks.
Next time if i'm using ovirt, i can sea automatically my defined city  
or building. Search and browsing is everything that we need to find  
something in future.
Or at this point where i attached a baremetal do a rack, this  
baremetal should be scanned and deployed to other frameworks  
automatically.
Over qmf are walking messages to cobbler for scanning this baremetal.  
cobbler send's back detail information about this baremetal if  
scanning is complete to all necessary frameworks.
In ovirt or other frameworks, i can see by browsing oder searching my  
defined city, building, baremetal, servers or customers. It depends on  
which logical view i have defined.
I read there are ideas for a qmf api for cobbler, libvirt-qpid is life.
You are right, this is a work in progress.

Thomas








More information about the ovirt-devel mailing list