On Mon, Oct 31, 2011 at 09:59:56PM +1100, Andrew Beekhof wrote:
> On 10/24/2011 05:40 AM, Livnat Peer wrote:
> >On 10/18/2011 05:05 PM, Adam Litke wrote:
> >>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.
> >>
> >
> >Another deployment strategy is:
> >
> >1. The data-center admin defines a customized policy.
> >He does that within the core-engine as this is the centralized
> >management tool he uses for managing the data-center.
> >
> >2. When adding a host to the data-center it pulls the policies from the
> >core-engine.
> >
> >3. The host is following/executing the policies (might also get fine
> >tuned parameters for specific host).
> >
> >4. If a policy needs some editing - we can edit the policy in the
> >engine-core and have it notify the hosts in the data-center about the
> >need to pull the new policies.
> >
> >One obvious advantage in the above approach is that it can be done once
> >and the system get's the policy distributed - no need for per host
> >action by the administrator.
> >Another advantage - the admin can set a more complicated policy that
> >optimizes behavior based on info of more than one host.
> >
> >We had previous discussions about policy-engines and pacemaker was one
> >option.
> >
> >If i understand correctly MOM is also executing a policy and not only
> >defining the policy so most likely there is a place for both
> >applications in the oVirt stack but it is better have them in sync early
> >in the process.
> >I think it might be interesting to have someone from the pacemaker team
> >on this thread.
> >Adding Andrew Beekhof IIRC he was on previous threads on this issue.
> 
> 
> If I'm reading the above properly, you're after something that
> figures out which objects (guests) go into which buckets (hosts) and
> in what order (including fencing and other types of recovery), so
> the the PE could well be a good fit.

Actually, I haven't tackled VM placement with MOM yet.  MOM is more about
dynamic optimization of a single host by adjusting tunables in response to the
observed conditions.  One way that MOM could "plug in" to a placement manager is
through a signaling mechanism.  If (for example) MOM determines that a host is
overloaded, it could use its policy to select a guest to evict and signal this
intention to a placement manager.  Then, the placement manager could actually
perform a live migration of the targeted guest.

More to the point, MOM optimizes a single host.  It sounds like Pacemaker might
be complimentary at the cluster level.

> 
> All the interesting stuff is in a C library but we also recently
> added Python bindings.  What language is being used here?

MOM is written in Python.

-- 
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