18 Replies
Last post:
Mar 12, 2008 11:31 AM by
Nick Stephen
I like the spread sheet that Greg put together. I especially like the func project due to my python bias. 
I think java has a bad rap in the agent world for being large and generally being written to shield you from the OS which is kind of what an agent needs to do. Also sys admins don't generally do java, they tend to like perl... Of course how to build the agent shell is really the easy part of this problem. The hard part is getting it everywere (ie shipped with the OS) and adding the "plugins" which actually make it do something.
As far as standards bodies go there is the DMTF which I derided in my talk. The CIMOM (open pegusus and OpenWBEM) which is the agent shell has some penatration. There is a lack of plugins though. I like the idea of BMC open sourcing the agent since it would have pretty good penatration already at large enterprises. Of course transitioning mature propriatary code to OSS has been quite tricky.
To Cote's piont about a third party standardization and coding it would be nice if the OMC could be that organization. Of course the companies in it are all young wiper snappers and it will be had for them to dedicate the resources to such an effort. I guess I would go back to a though from my other thread about net-snmp. If we could get the big platform players to contribute resouces to porting the agent there would be greater potential of success. Of course for them its not about resources as much as control of their platforms and the tools used to manage them.
-EAD
/me stands up and waves.
Hi. I'm one of the Func guys.
If any of you are interested in Func, I'd invite you to stop by https://fedorahosted.org/func and join the mailing list and IRC channel. Feel free to bring up whatever topics you like, and we're there for Q&A too.
I was on the OMC lists a while back -- and yes, I definitely agree that there is potential in this sort of thing and would love to see it happen. I too originally came from a Java/CIM world, have experience with both, and believe that (especially for a certain class of admins and FOSS developers), alternatives are great to have and are in some ways easier to build a community of admin/developers around.
If you have questions, or have ideas on how to move this forward, please let us know... preferably on the list, as I may forget to check back here -- though I'll try to remember
One of the obvious concerns are "do I have to use Python?" and/or Fedora/RHEL... thankfully, no. We do have some guys who have gotten Func running on Debian, SuSE, and FreeBSD... Windows is presumably doable... and someone has written a small Perl module that allows for calling Func minions. As those ports evolve, keeping those in tree, and maintained by the people who are interested in them is important... Minion modules do have to be written in Python presently, though there's nothing saying they can't in turn call other plugins and so forth... for instance NagIOS plugins are just stdin/stdout based and there's a simple module there already (too simple perhaps) for being able to hook into those.
As time goes on, I see the modules evolving and increasing in number... what's there now is really just a start and it's all pretty much changeable. Patches and other involvement is absolutely welcome. We're really concerned about making a framework that is extremely easy to contribute to, easy to understand, but also offers a secure communications channel that allows things to be audited and controlled in useful ways -- being able to schedule asychronous jobs, address servers in globs ("mailservers*.example.com") and so forth. If there are any features that seem to be missing (for instance, we don't have minion 2 minion communication implemented yet), please bring it up on the list or maybe contribute a patch. I think there are a lot of different places we could take this.
I look forward to seeing what can happen with this.
I will through ws-management into the mix... Its on windows and has some traction with two other implementations (and yey ones in java Having CIM as the core data model behind the agent seems like it would be a very good thing. Novell is doing it on linux so it must succeed! 