Bundles Best Practices

Table of Contents

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.

     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.