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:

When to make a bundle

Put items into a single bundle if:

Put items into different bundles if:

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 to use variables in common bundles

When to use variables in local bundles