On Tue, Nov 22, 2011 at 04:45:56PM -0500, Ayal Baron wrote:
> 
> 
> ----- Original Message -----
> > Hi guys,
> > 
> > I've got MOM up and running as a vdsm thread but I've hit two small
> > problems.
> > I'll bounce them around on the list to see if people have some ideas.
> > 
> > 1.) Libvirt SASL authentication
> > 
> > I was able to easily modify MOM to connect to libvirt by hardcoding
> > the vdsm
> > credentials.  Obviously this is not an acceptable long-term solution.
> >  What is
> > the best way to share the vdsm libvirt password with MOM in a way
> > that does not
> > compromise security?  Whatever method we choose should not involve
> > vdsm-specific
> > changes to MOM.  For starters I think I will just place the username
> > and
> > password in the mom.conf file.  We could make this file readable only
> > by the
> > vdsm user.  Thoughts?
> > 
> > 2.) Permissions
> > 
> > The first error I noticed was MOM failing to adjust KSM via sysfs:
> > 
> > 2011-11-22 10:13:48,313 - mom.Controllers.KSM - WARNING - KSM: Failed
> > to write
> > /sys/kernel/mm/ksm/run: Permission denied
> > 
> > MOM is used to running as root so that it can adjust these settings.
> >  I would
> > prefer not to complicate the MOM architecture by having a separate
> > process that
> > receives instructions from the main MOM thread and then applies the
> > requested
> > changes as root.
> > 
> > Another solution would be to allow MOM to run as a completely
> > separate daemon
> > (as it has been originally doing).  In this scenario, vdsm would
> > reconfigure MOM
> > by replacing the default configuration file and policy.  vdsm could
> > then
> > interact with the running momd via the existing xmlrpc interface.
> > 
> > Thoughts on these issues?
> 
> In continuation to our discussion from yesterday, both issues would be
> non-issues if we were to fully integrate MOM into vdsm.  However, I get the
> feeling we might be mixing things here.  Correct me if I'm wrong but the
> general architecture is: different data collectors -> MOM policy engine ->
> actions to perform 

Yes, you have the architecture correctly.

> Seeing as vdsm already today monitors and collects info from the guests, it
> should just be defined as a data collector and solve that side of the issue.

Yes, this should be just fine.

> Then we have the issue of performing the actions.  Currently mom executes
> these directly, right? if so, we could split that so that mom's output is a
> series of actions to perform which vdsm could then execute (if this sounds
> familiar it is because this is how pacemaker works and I think they got it
> right).

Yes, MOM currently executes the actions directly.  Given that the goal of
supervdsm is to provide a limited set of very specific actions, I am wondering
how extensible it will be for flexible management tasks.  I guess I will try it
out with KSM first and see how it would work.

> This means that in the vdsm-less scenario we would be missing an orchestrator,
> but that could easily be adapted.

In the vdsm-less scenario, we'd just use the existing sets of Collectors and
Controllers.

> Then whether the policy engine runs as a daemon or is just spawned internally
> is up to the application calling it.

Yes, this is how I have changed MOM to work now.  The RPM installs a system-wide
daemon that can be started.  Otherwise, an application can load the module,
configure it, and run it at will.

-- 
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