----- Original Message -----
From: "Michael D Day" <mdday@us.ibm.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: "Alexander Graf" <agraf@suse.de>, "board" <board@ovirt.org>, board-bounces@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@us.ibm.com http://code.ncultra.org