On 10/24/2011 08:03 AM, Ayal Baron wrote:
> ----- 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.

Ah, yes I recall that conversation.  Agreed.

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

Reply via email to