On Thu, Dec 08, 2011 at 10:04:45AM -0500, Ayal Baron wrote:
> 
> 
> ----- Original Message -----
> > On 12/08/2011 12:33 PM, Ayal Baron wrote:
> > >
> > >
> > > ----- 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?
> > 
> > A plan of first hosting MOM inside VDSM w/o committing to support
> > public
> > APIs. After definition/stabilization period it will be
> > possible/sensible
> > to spin off MOM for independence.
> > 
> > AFAIK, Dan and Adam are on board this plan, I can't understand from
> > the
> > email what's your opinion about it.

Well, that was not my original intent, but I'm perfectly fine with Vdsm
using `import mom` and gaining all its capabilities via an internal -
but well-defined - api. I hope mom would not have to spawn a root-owned
process for that, but even that is acceptable to me.

> > 
> > It doesn't matter how small you might keep MOM, it will take time to
> > define the right APIs and to commit for long term support. If
> > miraculously one might manage to do this really fast, then no problem
> > at
> > all. Reading previous posts, it seems like VDSM will get benefit of
> > that
> > too for its internal APIs
> 
> we can build it as a library from the get go, that would immediately make 
> sure we're passing things the right way and it wouldn't mean that mom has to 
> commit to a stable API.
> My take on it is that we shouldn't integrate with yet another daemon 
> competing on the same resources (VMs) and that full integration as part of 
> vdsm is wrong as well.

Dan.
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to