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
