raphdg
commented
11 years ago Thank you for your time and insight. Our intent was to briefly answer the number one question we received: 'How different are you than MCollective and Salt ?'. We've removed the table and instead focus on what we perceive as our key features.
First in general I'd say product comparisons as the one in your site is not generally helpful as no 1 person can sufficiently know all the products listed and make a fair comparison. But if you insist on having such a table I think it's important that you take feedback and correct any mistakes made.
I'd thus like to take the opportunity to correct your statements about mcollective.
Your bullet point list is extremely limited and does not really do mcollective and the other systems justice - hopefully you'll expand your comparison in time to be more representative of the typical feature set in tools in this space.
Overall the thing to know about MCollective is that everything is a plugin, the core does very little and has very few assumptions about what you do with it - past that everything from security to API to transport are provided through plugins and you can literally completely recompose MCollective into entirely different systems based solely on what kind of plugin you have. 13 types of plugin exist today providing the user with the opportunity to extend, enhance or shape their use of the system to their needs.
I hope the information provided below allow you to more accurately represent MCollective in your product comparison - but ideally I hope we can all live together and not play tit for tat games putting other products in this space down based on missinformation and that ultimately the comparison table will be removed and your product will stand on it's own merits.
Transport The MCollective connectivity system is plugin based and not tied to any one middleware system. Indeed ActiveMQ is the one used by most people but there are specific connectors for RabbitMQ and generic ones for stomp, ones have been written that communicate using AMQP and even more esoteric systems like MongoDB pubsub, databases and even email. Ones exist for QPID, HornetMQ and even JMS allowing MCollective to be hosted purely in the JVM. Indeed even SSH would be possible if I felt that made sense - the MCollective AAA system would map well to the unix user permission system and in this mode would allow for a serverless mcollective setup.
API The primary API is a RPC based system, there are REST gateways, IRC gateways, XMPP gateways and various others. Indeed through using the translation provided by ActiveMQ it would not be hard to support access via Websocket and various other protocols and systems
Further the API is not tied to any one model like request response, it supports promiscuously feeding information into other systems. It supports simple point to point 1 directional communications. It support a queueing behaviour or a broadcast non queueing mode and various other patterns in addition.
As with everything the actual protocol and indeed request model is a plugin - the entire RPC system can be extended, enhanced, replaced or augmented for your needs. You can in fact write your own style of API or many others and cohabit all on the same transport system in the same MCollective deploy.
OS Abstraction The mcollective core is OS agnostic as it runs on systems like iPhones, Windows, Unix, embedded in Java brokers like Tomcat and in various other esoteric locations.
We then provide a number of plugins that integrate with Puppet or Chef, directly with the OS, Java VM, manage deployed web app inside Tomcat as services or indeed whatever thing the user might need as this is a user serviceable plugin area.
As a simple example our package plugin at present supports 37 package systems and so many more operating systems as many operating systems share package managers. Likewise our service management supports 27 service providers. The package and service implementation is used widely - at a conservative guess the number is in the millions of systems managed by the underlying code base - it's well tested, trusted, feature full and reliable.
Internally MCollective is aware of system facts, these facts are usable by any plugin to influence their logic and plugins can provide confinement rules that activate them only on those operatingsystems or environments that provide the features they rely on. The facts can be provided using any means via a plugin system. Providers like Ohai, Facter, simple YAML files, text files and others are all supported already.
Data Format The data format is not set, its a function of the chosen security model you deploy and your API choice. It's not limited to anything and you can even use different ones at the same time if you can come up with reason for that to make sense.
As we've seen the API is a plugin and each API can do whatever data serialisation it wants. These can all cohabit and each do exactly what it is that make sense for their circumstance.
Access Control MCollective has a very capable full AAA stack.
Authentication - Users are identified using simple PSK or SSL certificates or even hardware token for true dual factor authentication. Again this is a plugin system and integration with systems like LDAP, Radius or whatever you want is completely possible. Integration has been written into systems like the standard SSH agent for centralized key based authentication.
Authorization - There is a rich role based authorization system that authorize users actions down to the action level with awareness of system facts and CM classes. User X can run service status on machines in production with apache installed but can restart services in all of development. This is an example of even the most trivial authorization construct. The authorization system supports modes like default allow or default deny either site wide or specific to a individual agent plugin. As with everything else authorization is done through a plugin so users can create their own authorization system that suits their needs.
Auditing - Every approved request is audited, audit plugins exist for systems like Splunk, Logstash, Centralized logging, log files per host or whatever you want really. Again this is a plugin interface and users can integrate mcollective into any auditing system that suits their business neeeds.
MCollective have quite a few other security features not strictly in the realm of Access Control. ACLs really is the most simple thing to consider there are levels of security required before and after ACLs come into play and MCollective has a very rich set of security features in addition to the ones listed above.
Language While the core is written in Ruby this is less relevant as users can mix and match languages to their hearts content. You can write a agent that manages one system and implement parts of this agent in ruby, others in perl, others in python and yet others in php. Other language support is trivially added and mcollective enables you to use the language that suits you best for the node side logic.
At present client side is primarily ruby - however C, Perl and Python implementation exist in the community.
Regards, R.I.Pienaar architect and principal author of MCollective.