[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