Re: oVirt project proposal: MOM
On Sat, Oct 15, 2011 at 11:05:09PM +0200, 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.
See my other response for why I don't think it is scalable to expose simple
knobs for each and every slight behavior modification we wish to perform.
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.
ovirt-engine would most certainly not self-program its own policy. My thinking
is that as a community, we would design a library of policies that are useful
for implementing a set of supported operating profiles (eg. aggressive
overcommitment, no overcommitment (SLA/guaranteed performance), power saving,
maintenance, etc). These policy files could be pushed (with modifications to
certain tunable parameters as required) to the appropriate nodes according to
user instructions or as deemed necessary by ovirt-engine. MOM's job is merely
to enforce whatever policy is given to it. To start with, we'll probably just
have a single policy (the current one) but I think we should keep ourselves open
to expansion.
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center