[VOTE] Inclusion of memory overcommit manager

[Itamar Heim]

On 09/28/2011 10:46 AM, Alexander Graf wrote:
> -1
>
> Can we please not do votes until we have a process on how to evaluate new project proposals? This feels very rushed.
>
> That said, I would probably vote +1 as soon as that process is in place (and from what I know about mom so far). I just don't like to rush things. So +1 for mom, -1 for the early vote :).

I also agree this feels a but rushed, and need a bit more looking into.
i don't think anyone disagrees on the need for something like that, or 
even on that exact implementation, but lets understand a bit better.

my main concern is if this is going to be "the" policy engine for vdsm 
going forward, is if it shouldn't be established on something which is a 
rule based technology (say, pacemaker).

could be it alrady is, could be it's not relevant, but let's understand 
the scope and strategy for something which will be the node level policy 
engine.

>
>
> Alex
>
>
>
> Am 27.09.2011 um 19:41 schrieb Carl Trieloff<cctrieloff at redhat.com>:
>
>>
>> This vote is to accept into oVirt the memory overcommit manager (mom)
>> project either to be used as a dependency in VDSM or as a daemon
>> alongside VDSM. This detail will be worked during integration.
>>
>> If the project is accepted and given it is our first community submitted
>> project to be voted we will create an infrastructure setup list which I
>> will record. This can then be used to make it easier for the next
>> project joining.
>>
>> Please vote -1, 0, +1 whether you would like to include this project
>> into oVirt.  I'll leave the vote open at least 72 hours.
>>
>> regards
>> Carl.
>> _______________________________________________
>> Board mailing list
>> Board at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/board
> _______________________________________________
> Board mailing list
> Board at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board