Re: Adding Memory Overcommitment Manager (MOM) to oVirt
----- Original Message -----
From: "Michael D Day" <mdday(a)us.ibm.com>
To: "Andrew Cathrow" <acathrow(a)redhat.com>
Cc: "Alexander Graf" <agraf(a)suse.de>, "board"
<board(a)ovirt.org>, board-bounces(a)ovirt.org
Sent: Tuesday, September 27, 2011 9:43:39 AM
Subject: Re: Adding Memory Overcommitment Manager (MOM) to oVirt
> > So what's the benefit of a separate MOM vs an integrated MOM
> > inside
> > of VDSM?
>
> I'd agree this is really VM policy which should be handled by VDSM.
It's pretty simple. MOM does something valuable today that VDSM
doesn't do. An integrated MOM inside of VDSM doesn't exist. If VDSM
wants to incorporate MOM that's great. But how is the existence of
VDSM an argument against contributing MOM source code to the oVirt
community? Am I missing something?
Sorry, I should have given a multi line reply, I was thinking a few steps ahead.
Bringing MOM under the oVirt umbrella would be a great thing - whether that's as a
standalone project or as part of VDSM.
Personally I believe it will/should end up as part of VDSM, but either way - if VDSM
leverages MOM (like it leverages libvirt) or if it gets merged into VDSM this should
happen under the oVirt umbrella.
Adding MOM to oVirt would be great and also helps to show momentum, maybe it remains
standalone or maybe it becomes part of VDSM, either way the path forward should start with
adding the project into oVirt.
Aic
On a related point, there are good examples that argue for
consolidating function inside a single daemon, and there are good
counterexamples. It's not always true that every node policy
function should be integrated within a single daemon. It probably
makes sense in this case. But again, VDSM doesn't do what MOM does
today, which is another argument in favor of contributing MOM and
letting the community work with it.
Thanks,
Mike
Mike Day
IBM Distinguished Engineer
Chief Virtualization Architect, Open Systems Development
Cell: +1 919 371-8786 | mdday(a)us.ibm.com
http://code.ncultra.org