The following contains practices to remember when creating bundles as you write policy.

How to choose and name bundles

Use the name of a bundle to represent a meaningful aspect of system administration, We recommend using a two- or three-part name that explains the context, general subject heading, and special instance. Names should be service-oriented in order to guide non-experts to understand what they are about.

For example:

  • app_mail_postfix
  • app_mail_mailman
  • app_web_apache
  • app_web_squid
  • app_web_php
  • app_db_mysql
  • garbage_collection
  • security_check_files
  • security_check_processes
  • system_name_resolution
  • system_xinetd
  • system_root_password
  • system_processes
  • system_files
  • win_active_directory
  • win_registry
  • win_services

When to make a bundle

Put items into a single bundle if:

  • They belong to the same conceptual aspect of system administration.
  • They do not need to be switched on or off independently.

Put items into different bundles if:

  • All of the promises in one bundle need to the checked before all of the promises in another bundle.
  • You need to re-use the promises with different parameters.

In general, keep the number of bundles to a minimum. This is a knowledge-management issue. Clarity comes from differentiation, but only if the number of items is small.

When to use a paramaterized bundle or method

If you need to arrange for a managed convergent collection or sequence of promises that will occur for a list of (multiple) names or promisers, then use a bundle to simplify the code.

Write the promises (which may or may not be ordered) using a parameter for the different names, and then call the method passing the list of names as a parameter to reduce the amount of code.

testbundle.cf
bundle agent testbundle
{
vars:

 "userlist" slist => { "mark", "jeang", "jonhenrik", "thomas", "eben" };

methods:

 "any" usebundle => subtest("$(userlist)");

}

###########################################

bundle agent subtest(user)

{
commands:

 "/bin/echo Fix $(user)";

files:

 "/home/$(user)/."

    create =>  "true";

reports:

 linux::

  "Finished doing stuff for $(user)";
}

When to use classes in common bundles

  • When you need to use them in multiple bundles (because classes defined in common bundles have global scope).

When to use variables in common bundles

  • For rationality, if the variable does not belong to any particular bundle, because it is used elsewhere. (Qualified variable names such as $(mybundle.myname) are always globally accessible, so this is a cosmetic issue.)

When to use variables in local bundles

  • If they are not needed outside the bundles.
  • If they are used for iteration (without qualified scope).
  • If they are tied to a specific aspect of system maintenance represented by the bundle, so that accessing $(bundle.var) adds clarity.