On Tue, Dec 06, 2011 at 12:42:24PM +0200, Dor Laor wrote:
> On 12/05/2011 03:55 PM, Adam Litke wrote:
> >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.
> It's not a reason to commit to two separate remote APIs that will be
> supported for a very long period.
> Modularization and internal apis should be achieved regardless.
> Moreover, since there is no modularization today, committing too
> early for new apis might cause us pains in the future.
> So my offer is to do the modularization and define apis between mom
> and vdsm but keep all internal. After a year we'll be able to judge
> whether we got the right set and might be worth to spin off MOM.

We let's give this plan a try.  Based on other planning and dicussions, vdsm is
going to gain quite a few new threads: QMF agent threads, REST API server
threads, MOM threads.  A good place to start poking might be to ensure that we
can handle the additional complexity that comes with these extra threads.

Adam Litke <a...@us.ibm.com>
IBM Linux Technology Center

vdsm-devel mailing list

Reply via email to