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.