Talk:Comparison of open source configuration management software

From Wikipedia, the free encyclopedia

I've thrown some theory into the ISconf dicussion that might be better in a different section; feel free to rearrange, and please clarify my application to the mentioned tools (Bcfg2, Puppet, cfenging, ISconf) and to classify other tools.

Forgot to sign previous talk entry: Thyrsus 21:59, 26 February 2007 (UTC)

Contents

[edit] Discussion of the article

I wonder where we should put the discussion part of the article. Not in the talk page :

The purpose of a Wikipedia talk page is to provide space for editors to discuss changes
to its associated article or project page. Article talk pages should not be used by 
editors as platforms for their personal views.

(Wikipedia:Talk_page_guidelines)

--Zethradon 15:09, 27 February 2007 (UTC)

Anyway, for now, I removed the discussion part of the article. Here's what was removed :

ISconf is controversial in its treatment of preconditions and postconditions of actions. Some tools, such as Bcfg2 and Puppet, require explicit descriptions of preconditions to hold before they apply an action, and further require an explicit description of postconditions, to be used by subsequent actions. Together, these have been called closure. Couch, Hart, Idhaw, Kallas Other tools, such as cfengine, don't make explicit the preconditions, but require their actions to be idempotent; thus an action may fail, but it keeps getting applied until some other action supplies the precondition, and then it succeeds - and keeps succeeding. These tools rely on convergence. Burgess ISconf differs in that it places no restriction on the nature of the action to be taken, nor any description of preconditions, but it requires that actions be applied to a known labeled state (e.g., a pristine OS install or system image), which after the action becomes a distinct state known only by its label; actions are always applied in identical order. This permits a theoretically perfect replicability. Traugott, Brown In practice, this model deals well with the often non-idempotent actions of package installation, but it can be expensive: actions either incorporate all the initial errors of the learning done by the sysadmin in creating a change, or the learning environment must be reimaged to a known prior state before the perfected performance of the action gets recorded; further, either any action performed with the machine whatsoever must be called an action and recorded, or actions must be accurately divided into either significant system actions and recorded, or else those concerning "only business data". An illustration of the difficulty: does a user account constitute significant system state or mere "business data"?

--Zethradon 16:40, 28 February 2007 (UTC)

[edit] Discussing features that are not present in all tools

We need to come up with a way to list features that are not part of all of the tools' management models, without implying that having or not having those features is preferable. Until then, below is some work on package and service management.

Djbclark 04:01, 17 April 2007 (UTC)

[edit] Package support

Note: This means that the tool has built-in knowledge of how to deal with the package format.

Bcfg2 Cfengine Puppet
apt-get / dpkg (deb) Yes Yes Yes
emerge (portage) Yes No Yes
epkg (encap) Yes No No
pkg-get (blastwave) Yes No Yes
pkgadd / pkg_add (sysv) Yes Yes Yes
port (macports) No No Yes
rpm Yes Yes Yes
up2date No No Yes
yum Yes No Yes
This is very unix/linux centric; windows has its own world. Furthermore, how would you define 'support'? Do you mean 'can install/uninstall' an RPM, then anything that can issue rpm commands can do it. More interesting is whether the tool can manage the lifecycle, and include in any health checks the presence of rpm -managed files.
More abstractly, you could view rpm and deb package manager tools as a form of CM software all of its own, if you push out custom RPMs that configure system state for your cluster. Its not very elegant, but it is possible. SteveLoughran 23:09, 25 October 2007 (UTC)

[edit] Service support

Note: This means that the tool has built-in knowledge on how to deal with the services.

Bcfg2 Cfengine Puppet
chkconfig Yes No Yes
launchctl (launchd) Yes No No
rc-update Yes No Yes
sv (runit) No [1] No No
svcadm (smf) Yes No Yes
update-rc.d Yes No Yes

[edit] See Also

[edit] References

  1. ^ Being worked on

[edit] External links clean up

There are way too many external links in this article and most of them should be deleted. The vendor links should all be internal. There really isn't much point linking to minor details like licensing or first release date. I know that we are supposed to cite facts on Wikipedia but that doesn't mean you are supposed to cite every possible fact. The links in the refs look good but I'd get rid of all the others. This might even help keep the spammers away too. (Requestion 06:01, 20 April 2007 (UTC))

Please geel free to ignore the comment I just left on your page, we crossed paths there a bit :-) -- in any case
  1. There was an attempt to make most of the vendor tags internal with stub articles, however people seem to have been deleting them (I just realized this - the most recent example being Bcfg2 - several people are editing this, so previously I just assumed that they had put in placeholders).
  2. Re: Licensing: This is not a "minor fact", it controls who can use the software, and how. The location of the actual text of the licenses is not always trivial to find (sometime in source control etc). Example use case: In many large companies, legal needs to vet all licensing, so links to the actual license documents would be useful for them.
  3. Re: First release date, in a comparison article this helps a person to determine how mature a piece of software is, and is therefor an important piece of information. Again this information is not always easy to search for.
  4. Software in this arena is in constant development. While I and others plan to keep this article up to date to the best of our abilities, we want to leave the reader (and possible future editors) with enough information to be able to update the article (i.e. if there is an external link to the current release page, it is so someone can verify that the wikipedia text is accurate, and then update it if need be; ditto for the OS support and security information)
  5. How excatly would having less external links keep spammers away? I thought Wikipedia was a search engine black hole anyway, so why would they care?
In general you need to have subject matter expertise in order to determine what is a "minor detail" in this article, so if you do not I would suggest handing this off to someone who does. Cheers, Djbclark 07:01, 20 April 2007 (UTC)
Would a good compromise be to make most of the other links references as well, or have a seperate "External Links" section (BTW are there tags to do that like with ref=?) Djbclark 07:07, 20 April 2007 (UTC)
I'm just trying to get this list to conform to WP:EL and WP:NOT policies. The licensing and initial release date columns are fine but they do not need to be referenced with external links. Has anyone questioned those facts and asked for citations? You could make them all references but that section is already huge. I would also recommend commenting out the vendor product links or moving them to this talk page since those types of links tend to be the spam magnets. For example, see the other lists in Category:Software comparisons. They don't have this exuberance of external links. Black hole? Unfortunately it seems like the spamming has only increased since the nofollow inclusion. (Requestion 15:27, 20 April 2007 (UTC))
I personally think its a lost cause to keep the latest version number and last release updated on this page. I just updated the puppet information as it was 5 releases and several months out of date. Providing this information when it is incorrect or outdated gives the comparison table a false comparison unless each is checked and updated before making a comparison that uses the latest release as a factor. --Micah2 18:37, 8 August 2007 (UTC)
I agree that product version info is trouble to keep up. This is something that could be left to the individual pages for each entry, assuming such entries don't get deleted for being unworthy. To make them worthy, we need decent content, but this must be factual/educational, not opinions/research. SteveLoughran 23:05, 25 October 2007 (UTC)
Micah, I see you are still keeping the puppet release info up to date. Now that there's a separate puppet page, I think the info could go there -and we could drop version/release info as a comparison. The only thing that matters in open source is is the project 'live' or 'dead'? If you use release newness as a metric you create bias towards projects that release frequently, rather than those that are stable. (SmartFrog gets release on a two/four week cycle, so showing release date would give us an advantage, but keeping it up to date is a maintenance cost I dont want to incur). —Preceding unsigned comment added by SteveLoughran (talk • contribs) 23:18, 24 December 2007 (UTC)