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