On Tue, Oct 18, 2011 at 11:33:40AM +0200, Dan Kenigsberg wrote:
> 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. If
> > a user plans to fence a node (in order to perform a hardware upgrade or for
> > some
> > other reason), we may want to push a different policy to that node while
> > virtual
> > 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 is
> > pretty basic but as we add additional control points and dependencies, the
> > system will become more complex. It will become increasingly more
> > difficult to
> > 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
> came up.
Sure. That is a sensible deployment strategy.
Adam Litke <a...@us.ibm.com>
IBM Linux Technology Center
vdsm-devel mailing list