----- Original Message -----
> > 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?
No one is against accepting MOM into oVirt, on the contrary, we really want it.
The only question is do we want to assimilate the code into vdsm or manage it as a
And the question here for me is just whether this would have other consumers (in which
case a separate project could make sense) or would vdsm be the only user (in which case it
at most should be a submodule).
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.
vdsm today does integrate (in a degenerated way) with ksm today (which is part of what mom
does), as mentioned before we're going to tweak page cache settings for 3.0GA and in
general vdsm does a lot of policy management and will do a lot more.
Obviously if vdsm did everything that mom does, then mom wouldn't be interesting at
IBM Distinguished Engineer
Chief Virtualization Architect, Open Systems Development
Cell: +1 919 371-8786 | mdday(a)us.ibm.com
Board mailing list