[Engine-devel] Proposed next-generation vdsm API

[Anthony Liguori]

On 12/01/2011 12:42 PM, Geert Jansen wrote:
>
> On 12/01/2011 07:35 PM, Adam Litke wrote:
>
>> A single-node (or standalone VDSM deployment) is a very important use case.
>> Many people are coming into the oVirt community from different perspectives.
>> The strength of the ecosystem depends, in part, on the ability of oVirt
>> components to be combined in unique ways with other software to produce
>> solutions.  The complete oVirt stack is a great thing, but not the only way to
>> use the technology.
>
> Just out of curiosity: what might those single node cases be, outside
> implementing an oVirt like solution?

ovirt-engine currently doesn't handle every possible scenario where you want to 
manage more than one physical machine.  And while I'm sure total world 
domination is not that far away, there's going to be a time period where there 
continues to be use cases it is not suited for.

To name a few:

1) Fixed environments where a handful of systems are needed with some level of 
scripting used to coordinate things.  Using a full three tier management server 
would be too much for this environment.  This isn't necessarily a small 
deployment, this may be a huge number of small deployments (think half a dozen 
blades in the back of a retail store times 5,000).

2) Massive scale clusters.  I'm talking Top 500 scale.  There are people out 
there doing this with KVM today.  They use tools like xCat and write directly 
against libvirt.  But libvirt's lack of policy makes this harder than it should be.

3) Environments where virtualization is not the primary workload.  There are a 
lot of cloud-like environments that are built with physical hardware only.  In 
these cases, there is an existing infrastructure that does a lot of what oVirt 
does.   It's easier for these environments to treat VMs as physical machines.

As much as it's important to focus on the top-down view of oVirt as a cohesive 
stack, it's also important to look at each layer and make sure that each layer 
stands on its own.

It's an 90/10 thing.  You need a strong node-level interface to cover that last 
10% of use-cases unless you're willing to spend 90% of the effort trying to also 
accommodate them.

Regards,

Anthony Liguori

> I think understanding those better
> is also critical input to the API design.
>
> Regards,
> Geert
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel