On Fri, Dec 02, 2011 at 02:54:17AM +0200, Dan Kenigsberg wrote: > On Tue, Nov 29, 2011 at 07:21:08PM +0000, Daniel P. Berrange wrote: > > On Tue, Nov 29, 2011 at 01:11:18PM -0600, Adam Litke wrote: > > > On Tue, Nov 29, 2011 at 05:44:23PM +0000, Daniel P. Berrange wrote: > > > > On Tue, Nov 29, 2011 at 11:18:42AM -0600, Adam Litke wrote: > > > > > On Tue, Nov 29, 2011 at 04:50:19PM +0000, Daniel P. Berrange wrote: > > > > > > On Tue, Nov 29, 2011 at 10:29:41AM -0600, 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 > > > > > > > > > > > > > > This RFC is about Plan A. I will start another thread to discuss > > > > > > > Plan B once I > > > > > > > have properly prototyped the idea in code. > > > > > > > > > > > > > > Integration VDSM and MOM at the OS level is by far the simpler > > > > > > > and least > > > > > > > intrusive option. As you can see from the included patch, the > > > > > > > changes to vdsm > > > > > > > are very limited. In this model, VDSM interacts with MOM in the > > > > > > > same way as it > > > > > > > uses libvirt. Upon installation, VDSM installs its own MOM > > > > > > > configuration file > > > > > > > and restarts the MOM daemon (which continues to exist as an > > > > > > > independent > > > > > > > system-level daemon). Once restarted, MOM will load its policy > > > > > > > from the VDSM > > > > > > > configuration directory. > > > > > > > > > > > > > > Pros: > > > > > > > - Simple and unobtrusive to either MOM or VDSM > > > > > > > - Clean API with no duplication or layering > > > > > > > - Maintain flexibility to tighten integration in the future > > Agreement is boring, but I prefer this approach, too. Vdsm is begging for a > modular breakup as it is; if we import mom into Vdsm, in no time we would be > tempted to avoid Vdsm API and create new dependencies.
Heh -- Boring? Maybe. Welcomed by me? Definitely! Thanks for your comments. > One comment regarding the suggested patch: I do not understand what is so > special about Vdsm that it should carry its own momd policy. It is not like > momd > has a gazillion of competing policies... I'd rather have momd deployed with > all > of the handful of policies we can device. Vdsm's task would be only to > configure > the default policy for momd to use on boot. Sure, that's fine. Actually for this patch I just copied the existing MOM policy to demonstrate the idea of vdsm shipping a policy. If we want it to remain with MOM that is fine by me. -- 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