Talk:Comparison of open-source configuration management software
From Wikipedia, the free encyclopedia
Telegram org
 | This article is rated List-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||
| |||||||||||||||||
.svg){kind=logo}
[untitled]
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. Thyrsus 21:59, 26 February 2007 (UTC)
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)
Really insightful, should this be in the ISconf article? 2001:A60:16B4:7001:5C0:D6E5:1CEE:197E (talk) 00:36, 24 September 2014 (UTC)
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)
Package support
Note: This means that the tool has built-in knowledge of how to deal with the package format.
- 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)
I am pretty sure CFEngine has yum support, we use that everydat at work .... (not sure how you verify the other operating systems, but usually in CFEngine you just define how to install/remove/upgrade software and it just works, so to install software for redhat based distros, use yum install, for suse, zypper whatever, etc etc). Misleading table. 31.151.153.51 (talk) 23:21, 18 December 2013 (UTC)
agree. misleading... 2001:A60:16B4:7001:5C0:D6E5:1CEE:197E (talk) 00:43, 24 September 2014 (UTC)
Service support
Note: This means that the tool has built-in knowledge on how to deal with the services.
This is somewhat biased. People reading this could be led to believe it is hard to manage daemons/services in CFEngine, whereas it is really easy. I have been doing it since 2000 with it, it is just a question of defining a class on the returnvalue of a shell command or ensuring a certain process is active (starting it otherwise). Could not get simpler that that.
See Also
- Thread on config-mgmt mailing list —The preceding unsigned comment was added by Djbclark (talk • contribs) 23:48, 17 April 2007 (UTC).
- Ziptie —Preceding unsigned comment added by 89.76.122.152 (talk) 23:13, 1 March 2008 (UTC)