On Sun, Dec 04, 2011 at 11:07:43PM +0200, Dor Laor wrote: > On 12/02/2011 04:15 PM, Adam Litke wrote: > >On Fri, Dec 02, 2011 at 03:08:24AM +0200, Dan Kenigsberg wrote: > >>On Thu, Dec 01, 2011 at 11:05:55AM +0200, Dor Laor wrote: > >>>On 11/29/2011 06:29 PM, Adam Litke wrote: > >>>>After discussing MOM / VDSM integration at length, two different > >>>>strategies have > >>>>emerged. I will call them Plan A and Plan B: > >>>> > >>>>Plan A: MOM integration at the OS/Packaging level > >>>>Plan B: MOM integration as a new VDSM thread > >>> > >>>I think a form of plan B is more appropriate: > >>> > >>>In general we can look at MOM vs VDSM just like micro kernel vs linux > >>>kernel approach. MOM can be independent project but then it will need to > >>>expose much more apis for VDSM and wise verse. > >>> > >>>For example, take live migration, there is no point of MOM balloon a > >>>guest while it is migrating. So either you ignore that which is bad or > >>>now need to listen to VDSM events on VM migration. > >>> > >>>Think about hot plug vcpu/pci-device to a VM - if before MOM used some > >>>SLA for the VM, now it will need to change to cope w/ the new resources, > >>>again more api/events for that. > >>> > >>>Another thing - all of the settings for per VM KSM/THP/Swap/Balloon - > >>>all will need to propagate from the vdsm api towards MOM. > >> > >>Indeed, disagreement is much more interesting! I think that the information > >>that Vdsm is expected to provide to momd is quite limitted and > >>slowly-changing. > >>We may be better off defining an API for Vdsm to notify momd of VM state > >>changes, than to entangle mom within Vdsm. > > > >Yep. We will need to write a MOM GuestVDSM Collector in order to gather > >statistics from vdsm guests. This Collector could also fetch guest events > >using > >the vdsm API. > > > > All these APIs are nice and required regardless if vdsm hosts MOM or > MOM is independent. Still, there is a *huge* difference in terms of > development speed and overhead by committing to external APIs. > > Correct me if I'm wrong but the only value of keeping MOM separate > is that it will be used as a general purpose policy tool for the OS.
This is one advantage, but cetainly not the only one. More importantly, as pointed out by Dan K. and Dan B., keeping it separate will encourage modularization which is greatly needed in vdsm. As part of this modularization, it will be easier to see, specifically, what MOM is allowed to do; making writing a SELinux policy for the policy engine much easier. > As I said before, I do think that there is a place for MOM like > functionality within the OS. But I think for the *best of ovirt > project goals*, it would be the most efficient to host all in VDSM > and keep our actions VM specific. > > I'm not that saying this to keep Dan.k interested :) > Dor > -- Adam Litke <a...@us.ibm.com> IBM Linux Technology Center _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
