----- Original Message -----
> 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.

Which plan?

In general, I think that Mom APIs should be kept separate from vdsm and vdsm 
would interact with a public mom API. On the other hand, I do not think mom 
should be a daemon as that quickly leads to it keeping a lot of state that 
needs to be synchronized between vdsm and mom.
You gave libvirt as an example, but it is a very bad one as the architecture 
there is sub par at most.  Suffice it to see that the #loc when vdsm 
communicated directly with qemu was smaller than it is now going through 
libvirt without additional direct functionality (there is a lot that we gained 
using libvirt in the form of svirt and other configurations libvirt does, but 
this should not have affected the integration at all).
The reason for the code bloat is having to synchronize 2 stateful daemons.  I 
believe that were libvirt actually a lib things would have been much simpler 
and more straight-forward.
I think the same applies to mom.

Because mom is a generic policy engine then it stands to reason that any 
mom-client would want the following:

1. send mom client's current state and rules/policy
2. mom would compute required state changes
3. run client specific changes.

Doing number 3 would require either integrating with the client's public API or 
just pass back to the client a list of required changes and have it execute 
I don't think that using the public API in this scenario is the right thing to 

I think that the current mom implementation mixes the client and the engine 
If you separate current mom into 2 projects, the rule engine and the rest (data 
collectors and execution of actions) you will find that the engine needs no 
special privileges at all.
The current mapping problem is that you're trying to use the client you already 
wrote with vdsm which is wrong, as vdsm already has collectors of its own and 
knows the problem specific actions that it can run.  The confusion stems from 
the fact that the problem domain is the same (throttling VMs).

> --
> 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
vdsm-devel mailing list

Reply via email to