----- 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 separate project. 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 all.
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
_______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board