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

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

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.

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


vdsm-devel mailing list

Reply via email to