----- Original Message -----
> 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.


1-4 Are fine and supported with Dan's approach (vdsm exposes a set of 
parameters, engine sets policy).

> Another advantage - the admin can set a more complicated policy that
> optimizes behavior based on info of more than one host.

throttles memory usage across hosts? cpu?
Also, if you push the policy down to the host, how would the host get the info 
from other hosts?


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

We've already discussed this with Andrew and Pacemaker does not support 
throttling, only on-off. Introducing throttling in pacemaker (which uses lisp 
for the rule language) for 5K loc in python doesn't seem like the way to go.

> 
> The way i see it we need a policy engine in the oVirt stack, I think
> that integration for defining the policy should be at the
> oVirt-engine
> level, the integration for the execution of the policy should be in
> host
> level but we better have a "common-language".
> 
> Livnat
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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

Reply via email to