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.
All the interesting stuff is in a C library but we also recently added
Python bindings. What language is being used here?
>
> 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
