Platform Team/Server Kit/Mace: Difference between revisions

Line 3:

The mace is a tool to ma<strike>c</strike>ke final configuration using source templates. Mace is supposed to help with configuration of services on Server based school servers.

These are the core differences compared with tools like Puppet or Cfengine that makes mace different niche project:

These are the core differences compared with tools like Puppet or Cfengine that makes mace a different niche project:

* mace provides simple and straightforward usage workflow, i.e., with tools like Puppet, users need to ''"code"'' configuration (starting from regular coding in Ruby for ~~missed function~~ or types, and ending by handling ~~relations~~ between all configured resources)~~; it~~ is different in mace, users only need to ~~type~~ configuration for the particular service, the rest (like dependencies between configured services) is already coded in mace;

* mace provides a simple and straightforward usage workflow, i.e., with tools like Puppet, users need to ''"code"'' a configuration (starting from regular coding in Ruby for missing functions or types, and ending with handling the relationships between all configured resources). It is different in mace; users only need to enter a configuration for the particular service, the rest (like dependencies between configured services) is already coded in mace;

* mace doesn't provide new metaphors, people need to follow the ~~same~~ configuration syntax for particular ~~services~~;

* mace doesn't provide new metaphors; people need to follow the standard configuration syntax for any particular service;

* mace is not intended to be a unified system like Puppet or ~~Cfenginei,~~ it supports only a limited set of services (~~what~~ Server based solution provides), but does it well, e.g., for iptables, just write rules, and the rest will be done by mace;

* mace is not intended to be a unified system like Puppet or Cfengine; it supports only a limited set of services (of those that the Server based solution provides), but does it well, e.g., for iptables, just write rules, and the rest will be done by mace;

* mace doesn't function like a daemon, it just converts configuration sources to the final configuration on the final server, e.g., as a post procedure after installing packages;

* mace doesn't function like a daemon; it just converts configuration sources to the final configuration on the final server, e.g., as a post procedure after installing packages;

* mace is designed to ~~easy~~ support of intermediate customizing, i.e., the original configuration, provided by an upstream project, might be supplemented (not patched) in the downstream product before deploying to the final users.

* mace is designed to ease support of intermediate customizing, i.e., the original configuration, provided by an upstream project, might be supplemented (not patched) in the downstream product before deploying it to the final users.

== Configuration sources ==

@@ Line 3: / Line 3: @@
 The mace is a tool to ma<strike>c</strike>ke final configuration using source templates. Mace is supposed to help with configuration of services on Server based school servers.
-These are the core differences compared with tools like Puppet or Cfengine that makes mace different niche project:
+These are the core differences compared with tools like Puppet or Cfengine that makes mace a different niche project:
-* mace provides simple and straightforward usage workflow, i.e., with tools like Puppet, users need to ''"code"'' configuration (starting from regular coding in Ruby for missed function or types, and ending by handling relations between all configured resources); it is different in mace, users only need to type configuration for the particular service, the rest (like dependencies between configured services) is already coded in mace;
+* mace provides a simple and straightforward usage workflow, i.e., with tools like Puppet, users need to ''"code"'' a configuration (starting from regular coding in Ruby for missing functions or types, and ending with handling the relationships between all configured resources). It is different in mace; users only need to enter a configuration for the particular service, the rest (like dependencies between configured services) is already coded in mace;
-* mace doesn't provide new metaphors, people need to follow the same configuration syntax for particular services;
+* mace doesn't provide new metaphors; people need to follow the standard configuration syntax for any particular service;
-* mace is not intended to be a unified system like Puppet or Cfenginei, it supports only a limited set of services (what Server based solution provides), but does it well, e.g., for iptables, just write rules, and the rest will be done by mace;
+* mace is not intended to be a unified system like Puppet or Cfengine; it supports only a limited set of services (of those that the Server based solution provides), but does it well, e.g., for iptables, just write rules, and the rest will be done by mace;
-* mace doesn't function like a daemon, it just converts configuration sources to the final configuration on the final server, e.g., as a post procedure after installing packages;
+* mace doesn't function like a daemon; it just converts configuration sources to the final configuration on the final server, e.g., as a post procedure after installing packages;
-* mace is designed to easy support of intermediate customizing, i.e., the original configuration, provided by an upstream project, might be supplemented (not patched) in the downstream product before deploying to the final users.
+* mace is designed to ease support of intermediate customizing, i.e., the original configuration, provided by an upstream project, might be supplemented (not patched) in the downstream product before deploying it to the final users.
 == Configuration sources ==