[VOTE] Inclusion of memory overcommit manager

[Anthony Liguori]

On 09/27/2011 02:04 PM, Carl Trieloff wrote:
> On 09/27/2011 02:34 PM, Anthony Liguori wrote:
>> -0.9
>>
>> I don't think we should rush into adding projects.  I think there's an
>> open question of whether MOM should be folded into VDSM or whether it
>> should be stand alone.
>>
>> I'd like to see a roadmap for either integrating into VDSM or a clear
>> (agreed upon) description of what components own what functionality.
>>
>> My concern is that having MOM be an oVirt project would discourage
>> attempts to merge MOM into VDSM.
>>
>> N.B. my vote is non-binding.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>
>> On 09/27/2011 12:41 PM, Carl Trieloff wrote:
>>>
>>> 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.
>
> It sounds like the next step is for the mom and vdsm project to have a
> discussion and come back to the list. The discussion should clarify.
>
> a.) mom is an additional daemon that wdsm would use
> b.) mom is a library that vdsm would use
> c.) mom gets included into vdsm.
>
> Either (a or b) would mean we create another project. (c) would mean we
> deal with it as a code contribution to the vdsm project.
>
> Anthony, Perry, I take it your concern is we don't want to setup a
> project if technically we include the mom as a code submission - option
> (c).  I had assumed a or b, your concern as I read it is to rule c
> in/out before completed this vote.

Correct.

Regards,

Anthony Liguori