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.

> > > > > > 
> > > > > > Cons:
> > > > > > - Momd runs as root (like supervdsm)
> > > > > > - If MOM will consume VDSM APIs, it must use the slower xmlrpc 
> > > > > > interface
> > > > > 
> > > > > I curious about the 'runs as root' bit. By listing it as a Con here,
> > > > > you imply that if it were a VDSM thread, it could run as non-root ?
> > > > > What is it that Momd has todo that requires root when run outside
> > > > > of VDSM, yet is not a problem when inside VDSM ? IOW can it not be
> > > > > made to run as 'momd' user/group when standalone ?
> > > > 
> > > > Very good questions -- thanks for raising them.  I've listed it as a 
> > > > con because
> > > > others have raised it as a concern.  MOM runs as root for a few 
> > > > reasons: to
> > > > connect to the qemu:///system libvirt URI, to connect to guest agent 
> > > > sockets,
> > > > and (most difficult to mitigate) to reconfigure KSM via sysfs.  As MOMs
> > > > Controllers expand in functionality the need to root access will 
> > > > increase.
> > > 
> > > FWIW, connecitng to qemu:///system does not require root. Traditionally 
> > > VDSM
> > > configures SASL, so all that would be required is to create a SASL 
> > > username
> > > and password for Momd. Alternatively if the default policykit auth is in
> > > effect for libvirtd, the mom RPM could simply drop a policy file into the
> > > right location to allow processes under the 'momd' UNIX user to connect.
> > 
> > Yep.  I've already got a patch for MOM to use SASL for libvirt connections.
> >  
> > > I don't have a clear answer for the KSM thing & other tunables momd might
> > > need to deal with. There is perhaps a gap here for a system tunable daemon
> > > to provide an RPC service over DBus, which momd then uses to change sysfs
> > > tunables. Or something...
> > 
> > At the end of the day We have to let something be root, why not MOMd?  It is
> > already slim and narrowly focused on stats collection and response.  
> > Introducing
> > yet another daemon just adds complexity and requires us to change more
> > components each time we want to do something.  A "generic" tunable daemon 
> > would
> > likely not be part of oVirt and would not adhere to our release cadence; 
> > thus
> > decreasing our ability to add new functionality.

It does not have to be generic - the standard way to solve this problem is for
momd to walk the supervdsm route (but do it properly): start as root, fork,
setuid(mom). The root-owned parent can expose a very limitted set of functions
(tune ksm, deflate guest X) to its more complex child.


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.

Dan.

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

Reply via email to