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

Reply via email to