On Mon, Oct 17, 2011 at 09:03:41AM -0500, Adam Litke 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.
> > Y.
> One example I might put forth is a policy that cooperates with node fencing.
> a user plans to fence a node (in order to perform a hardware upgrade or for
> other reason), we may want to push a different policy to that node while
> machines are migrated away from it.
> Some may argue that this could be implemented in a permanent policy through
> manipulation of simple variables. I don't tend to agree. The current policy
> pretty basic but as we add additional control points and dependencies, the
> system will become more complex. It will become increasingly more difficult
> write a comprehensive policy that can expose enough simple 'control knobs' to
> achieve the desired results for all of the potential use cases.
It makes perfect sense to expose a knob to choose a policy. I'm
repeating myself repeating myself, but I see the policy(ies) as static
entities, that are unlikely to change during a product release.
Architecture is much simpler if the policies are expected to sit on the
node and not transfered by ovirt-engine when it senses that the host
vdsm-devel mailing list