On 10/15/2011 11:05 PM, Dan Kenigsberg wrote:
> On Sat, Oct 15, 2011 at 10:34:55PM +0200, Yaniv Kaul wrote:
>> On 10/15/2011 10:19 PM, Dan Kenigsberg wrote:
>> <SNIP>
>>> I find it quite awkward for ovirt-engine to send code to MOM. It is not 
>>> like the
>>> programmers of ovirt-engine are smarter than you and could devise a better
>>> policy. It *is* important to have "ballooning profiles" attached to guests 
>>> (e.g.
>>> "this VM is holy, do not balloon unless host is in deep manure") or hosts 
>>> ("keep
>>> 100Mb free at all costs"). I think that defining the available profiles is 
>>> the
>>> business of MOM - no one can do it better.
>>> Dan.
>> I disagree, for one reason - the engine has an overall view of the
>> system, not just of a single node.
>> However, I haven't found yet where it can be advantage. I'm sure
>> there are such cases, though.
>> The knowledge of an operating system, its properties (to which user
>> it belongs, its priority, is it related to another VM, ...) probably
>> has some value.
> Sure, but these should be a finite set policies and their parameters. 
> Management
> layer should be provided with useful knobs and handles, not the ability to 
> push
> generic code.
> Can you ever envisage ovirt-engine compiling a completely new policy on its 
> own
> volition? This would require AI capabilities out of its current scope. The
> Engine may have several policies dumped in its database, and it would have to
> apply one of them to a host every time it changes to Up. The only advantage I
> see in this is that introducing a new policy in a new Engine version is 
> simpler,
> and does not require updating all of its nodes.
> Dan.

Unless the customers want to write their own policies.

vdsm-devel mailing list

Reply via email to