More thoughts and comments. We've been chatting on the thebes-l list, and it would seem that all we would want to add from the security perspective is a pointer to one or more metadata documents, which would then hold anything useful to the security system. That would minimize the impact this plan would have on the XML.
While it would be wonderful if all batch schedulers adopted this language as a standard, it is actually unnecessary. We can still implement something with this for the initial resource discovery and introduction, then pass the submission and monitoring of the jobs off to the resource batch scheduler. Arnie Seth Graham wrote: > Jesse Becker wrote: > >> Bernard Li wrote: >> >> >>> While not exactly what you have in mind, but have you taken a look at >>> the JobMonarch project? >>> >>> https://subtrac.sara.nl/oss/jobmonarch/ >>> >>> AFAIK it does also work with SGE. >>> >> Meh...not really. It's under development, and doesn't work so well >> with the 6.x versions. I think it works with the old 5.3 series though. >> > > job monarch reveals a flaw with PBS (what we use, I imagine this isn't a > unique trait) in the sense that the worker nodes do not have the > capacity to report job information. Job monarch can only run on the > central server.. which makes ganglia, due to its distributed nature, a > poor partner. > > If I'm understanding the goal of the Thebes project, they would try to > get the authors of batch system software to adopt a more "ganglia like" > approach to reporting statistics.. which I'd be happy to see. > > The concern I have is overloading the metrics held in memory by a gmond > process to the point it starts consuming noticeable amounts of > resources. Ganglia's xml output is by far my favorite feature of the > program, the xml is easy to parse and use for homegrown monitoring > tools. I worry that if ganglia became a default dumping ground for > service information the xml would become inconvenient to work with. > > The other downside I see is the nature of the data itself. Job > information from a batch system is not something you can stuff into an > RRD.. you'd have to develop some other way to store job history > information, a task that would put a greater load on gmetad and > introduce additional scalability concerns. My second favorite feature of > ganglia is how simple it is, and I don't know if I'd appreciate it the > same way if an installation had a dependency tree as long as my arm. > > > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Ganglia-general mailing list > Ganglia-general@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ganglia-general > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Ganglia-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general
