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
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to