Intro

The SUSE Manager client stack is rather simple, in regular intervals it asks the SUSE Manager Server for scheduled actions and executes them. Typical actions are:

install patch
install/update/remove package
verify contents of config files

Problems addressed

There are a couple of issues with this approach:

scalability: load on server and database each time a client asks for actions - even if no actions are scheduled
scalability: server can't cope with many clients requesting actions within a scheduled maintenance window
availability: client actions depend on the server, if the server is down / not reachable, the client can't perform actions
availabilty: we have many requests to support low bandwidth connections and remote locations
compliance: clients are not compliant to the desired configuration in between intervals
rogue sysadmins: admins still run zypper or rpm on managed clients, circumventing the desired configuration defined on the server
DRY: the majority of actions are supported by standard configuration management systems, no need to duplicate them in a separate client stack
limited to packages, patches, and complete config files, no services, processes, etc.
decrease of disk space. Adding the client software stack to a minimal SLES system adds a couple of dozen megabytes
synchronous operation: clients carrying out an action must contact the server. This easily overloads the server if you have many clients and a short maintenance window.

Goals to achieve

Using an existing configuration management software, I want to achieve the following goals

move from imperative (action based) to declarative (policy based) configuration settings
scalability: decrease load on server - server generates policies, client applies policies without interacting with the server
scalability: maintenance window times should be a part of policies, where clients should operate autonomously within the maintenance window
scalability: clients might re-distribute policies to other clients
availability: client operates autonomously
availability: with a local update repository, only policies need to be transferred, with minimized bandwidth requirements
compliance: configuration management can enforce policy on client more often and report or remediate actions done by rogue sysadmins
DRY: drop homegrown client stack in favor of community adopted existing software instead
extend to parameterized config file templates, localized change within an existing config file, control of services, processes, etc.
minimized disk space requirements - e.g. CFEngine needs around 10 megabytes
reporting: client status (list of package, hardware information, etc.) back to the server.
asynchronous operation: separate 'prepare client for the change' from 'apply the change'. Prepare all clients (download list of changes to be applied, download required packages and patches) before the actual maintenance window. Clients should be able to operate autonomously, without the need to contact the server while applying a configuration change.
Monitoring: any decent CMS can do monitoring and even react for required events. There is how monitoring could be "integrated".

Approach

Use an existing configuration management system (CMS). Deploy the master of the CMS on the SUSE Manager Server and the slave of the CMS on the client system. Write a small daemon which runs on the server and translates actions to policies. Distribute these policies via the existing CMS master-slave deployment mechanism and let the client operate autonomously.