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

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

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

> --
> 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
vdsm-devel mailing list

Reply via email to