Configuration Management System:
In this post we will discuss about the Imperative versus Declarative in Configuration Management Systems, Contention between various configuration management systems is the concept of declarative versus imperative configurations.
imperative:
It may be easiest to think of imperative programming like a script:
perform Task 1
and, when it is finished, perform Task 2; once that has finished, perform Task 3. This is what many administrators are used to, especially as it more closely resembles the shell scripts that have been their lifelines for so many decades.
Chef is an example of a configuration management suite that is imperative in nature.
Declarative:
It is a newer concept and more representative of object oriented programming.
The basic idea is, the user declares which tasks need to be performed and the software performs them in whichever order it sees fit.
Generally, dependencies can also be declared that dictate that some tasks are not to be completed until others are.
Puppet is a well-known example of a configuration management platform that is declarative in nature.
Imperative versus Declarative in SaltStack:
In our case – SALTSTACK:
Salt is unique in that it supports both imperative ordering and declarative execution.If no dependencies are defined then, by default Salt will attempt to execute States in the order in which they appear in the SLS files.
If dependencies are defined, States will be handled differently. They will still be evaluated in the order in which they appear, but dependencies can cause them to be executed in a different order. Consider the following Salt
State:
apache_service:
service.running:
– name: httpd
apche_pkg:
pkg.installed:
– name: httpd
apache_file:
file.managed:
– name: /etc/httpd/conf/httpd.conf
– source: salt://httpd.conf
In the first several versions of Salt that supported States, this would have been evaluated lexicographically: the file would have been copied into place first, then the package installed, then the service started, because in the English alphabet, F comes before P, and P comes before S. Happily, this is also the order that is probably desired.
Diving into Salt Internals
However, the default ordering system now in Salt is imperative, meaning States will be evaluated in the order in which they appear. Salt will attempt to start the apache service, which will fail because the package is not installed. It will then attempt to install the apache package, which will succeed. If this is a Debian-based system, installation of the package will also cause the service to start, in this case without the correct configuration file.
Lastly, Salt will copy the configuratoin file into place, but will make no attempt to restart the service to apply the correct changes. A second State run will report success for all three States (the service is running, the package is installed, and the file is managed as requested), but a manual restart of the apache service will still be.
Requisites:
To overcome the ordering issues Salt uses requisites,
Requisites(https://docs.saltstack.com/en/latest/ref/states/requisites.html)
will affect the order in which States are evaluated and executed.
apache_service:
service.running:
– name: httpd
– require:
– pkg: apache_service
– watch:
– file: apache_service
pkg.installed:
– name: httpd
– require:
– file: apache_service
file.managed:
– source: salt://httpd1.conf
– name: /etc/httpd/conf/httpd.conf
The order that will be defined in the state file is like,
service, pkg and file manage order. But the service require the apache pkg to execute first, so before executing the apache service, it will look ahead and evaluate the apache package. But, since it requires the apache config file to be executed first, it will jump ahead and evaluate the apache config file.
Once the service state completed successfully then it will check the next state and see if it has already been executed. It will continue in this fashion until all States have been evaluated and executed.
