----- Original Message -----
> 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.
Customers would be allowed to write their own policies but that does not mean
write code.
A policy would be defined by the finite set of parameters we allow to tweak.
The fact that mom works with a rule language does not mean that that is the
level we need to expose to rhevm.
vdsm can define the set of policies and the parameters we wish to expose in the
higher level API.
I think MOM generality will prove to be a good thing the more we add abilities
(policies involving I/O and CPU and Network and combinations of all of the
above).
> Y.
>
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel@lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel
>
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel
