Policy setup and structure

The current version of the Webhuis CFEngine policies are an evolution of Dynamic CFEngine.

More on Roles

The concept of roles is at the heart of the Webhuis show case solution. The role defines the system in every aspect.

• The hardware it has available
• The software it autonomously installs, configures and runs

Many roles look similar when it comes to many configuration aspects, but there always are those little differences. Those differences prevent the definition of a generic policy and provide redundancy in policies at best. Large parts of the role redundantly define the promises.

The policy matrix

The bundles containing the policies tend to get large and complex, because of the need to find taylor made solutions for generic problems in different environments and software components that appear in versions that at times are hampered by fundamental change.

The need to improve Dynamic CFEngine

Dynamic CFEngine to a large extent meets the requirement of having only the relevant policies in place, which reduces both the amount of code and the complexity of the code. The way Dynamic CFEngine is structured, however, has some draw backs.
Convergence is one of the fundamental principles of CFEngine the dynamic setup relies on too heavily, because policies are being used to identify dependent and subsequent policies. Policies are being derived from the concept of the 'role' a system has, components are defined in the role and convergently become available to the system. A role has one or more components that may depend on the platform or the flavor of the system. Convergence towards the Desired State is meant for configuring a system, not for the composition of the policy set.

• This may lead to a temporarily inconsistent policy set
• Developers tend to reject this setup, they want to have the policy set available right from the beginning
• The role concept as it was, was far from perfect, because of the redundancy in the different roles.

Enter the Role Profile concept.

Role Profile

The concept of 'role' and components had to be refined in order to meet the requirement of generic policies, while avoiding redundancy. Many roles look very similar when it comes to the definition of:

• Interfaces, usually a common interface and an admin interface
• Infrastructural components, like host name resolution and time configuration
• Platform components, the most commonly used standard software

Many roles share very basic profile following the description above, the standard support profile, the profile consists of a set of policies and templates. The CFEngine policy hub is a bare Linux machine and has the most basic role imaginable, cfeh. It still configures itself with the common policies and templates available. The standard support role profile, std_sup, is derived from this set of policies.

Implementation

The identified elements of the standard support role profile reside in the policies tree in the subdirectory 'pool' under roadshow_polies, the policies in bundles and templates in templates, These bundles and templates are very common and are thus available to other roles through role_profile. The profile definitions reside in the profiles directory, per role. Each role contains a bundles and a template direcotry, which in this case, only contain symbolic links to file in the subsequent pool subdirectories bundles and templates.

Pool of profile, bundles and templates

└── roadshow_policies
    ├── pool
    │   ├── bundles
    │   │   ├── resolv_conf.cf
    │   ├── profiles
    │   │   └── std_sup
    │   │       ├── bundles
    │   │       │   ├── resolv_conf.cf -> ../../../bundles/resolv_conf.cf
    │   │       └── templates
    │   │           ├── resolv.conf.tmpl -> ../../../templates/resolv.conf.tmpl
    │   │   ├── templates
    │   │   │   ├── resolv.conf.tmpl
    ├── roles
    │   ├── cfeh
    │   │   ├── bundles -> ../../pool/profiles/std_sup/bundles/
    │   │   └── templates -> ../../pool/profiles/std_sup/templates/

---

Return to: CFEngine