Who should not set configuration once a system is up and running

Traditionally, northbound interface users are the ones in charge of providing configuration data for systems.

In some systems, we see a deviation from this traditional practice; allowing systems to configure “themselves” behind the scenes (or behind the users back).

While there might be a business case for such a practice, this kind of configuration remains “dangerous” from northbound users perspective and makes systems hard to predict and even harder to debug. This is without mentioning that the business need can be formulated in a different format that can allow for a better solution.

An example that can illustrate such a need would be the configuration of ports.

A system might be designed in a way that allows it to “self” configure itself by creating port configuration once supporting hardware is dynamically detected (interface cards inserted i a chassis based system for example).

This practice sounds Ok but hides future problems with regards to managers (NMS, EMS, ETC…) and to the overall management experience.

With the advent of transactional Network configuration, this practice can not work anymore.
The fact that systems are given the right to change configuration is a key here in breaking transactional configuration in a Network.

Imagine a remote management application that is trying to configure device A and B and C in one single transaction; device A required port configuration (The system already took care of that when the supporting hardware was detected => self configuration), the result of the configuration to be applied on A and B and C was a successful configuration commit.

After A, B and C were successfully configured in a transactional manner, a supporting hardware for configuration A was pulled. A, then, goes ahead and deletes the previously committed configuration. This results in breaking the initial transaction that involved A, B and C and the manager has no way to know what happened unless A notifies the manager somehow which in turn has to figure out how to revert B and C…

You can see the complexity that can arise from system driven configuration when looking at the whole management requirement and specifically at transactional configuration management.

A way to solve this problem is to design the system in a way that restricts configuration to be driven by northbound users only, along with factory based configuration. Configuration should always be allowed whether hardware is present or not and whether the machine is in a certain state or another.

Problems like configuration mismatch (with the hardware or a machine state), can be dealt with using alarms or some other recovery mechanism but can never be dealt with by allowing the system to modify configuration without the knowledge of the northbound users and outside of the transactional ecosystem.

That being said, a system can still set its configuration before it is fully operational as northbound managers haven’t synced configuration yet and haven’t started involving the system in Network wide transactions.

In ConfD, there are different ways to set configuration at the startup phase:

1- Using xml unit files can be useful when starting from a clean slate database.
2- Applications running on the system can synchronize their configuration and write it to CDB, for example, prior to opening Northbound interfaces. This is possible by starting ConfD up to phase 1, writing data in CDB, then starting ConfD in phase 2 in order to provide northbound users access to CDB.