[joshuamorton]

> Declarative systems work by generating the desired state 'from scratch', often with some kind of efficient cache.

This is an option, but it is certainly not a requirement. If I say "I want cheeseburger", it is irrelevant to me if the cheeseburger is made from scratch or had been partially assembled ahead of time.

You are concerning yourself solely with configuration that can be generated not only declaratively, but also fully deterministically, but configuration systems can indeed exist where the environment isn't sufficiently deterministic. In such cases, taking the current state of the world, the user's request, and then determining the appropriate (and preferably minimal) actions to take to harmonize those without having to have them specified by the user is a declarative approach.

For example, I can go to the AWS console and turn up a job with a set of parameters, or I can have a configuration file and a daemon and if

    {
        cpu: 5,
        mem: 20,
        image: "my_docker_url",
     }

is present in that file, I can then assume a job meeting those specifications exists, and if not present the job will not exist. The daemon might do this by shutting down all the jobs and starting new ones every time the file is parsed, but that is probably not great. Approaches that only restart changed jobs, or which can dynamically resize jobs that support such things might lead to significantly better performance of th esystem as a whole.

[pxc]

I completely agree! I mistakenly ommitted the word 'can' from the quoted sentence. I just meant to offer another example of declarative configuration management. The style of configuration/automation (of a config management tool) can be declarative whether the implementation has to consider the current state of the system or not.