Cloud-init's configuration modules are not idempotent. Some modules attempt to be, but most are not idempotent. Some modules cannot be idempotent, because they allow arbitrary code execution.
Instead of idempotent configuration module implementations, cloud-init uses a frequency-based system. Cloud-config modules run at a frequency of PER_INSTANCE, PER_BOOT, PER_ONCE, or PER_ALWAYS. These frequencies are sensible given the lifecycle of cloud-init instances and the non-declarative nature of its configuration.
Looking at cloud-init through the lens of configuration management, the user interface and frequency-based argument doesn't make as much sense. An ideal user interface would be declarative, and an ideal implementation would be idempotent, and running the command manually would set cloud-init to the declared state regardless of the starting state, and running a configuration module on one platform versus the next cloud produces the same outcomes given the same input configuration (decouple datasource-specific code from platform-specific magic).
Since using cloud-init as a manual configuration tool outside of first boot is not an uncommon request, and since using cloud-init as a configuration tool has long been possible by some un-intuitive and not-well documented (or tested!!!) commands, I propose that to raise the bar initially by creating a set of generic idempotency tests by which we can measure, and therefore improve, the state of cloud-init as a manual configuration tool.
These tests aught to generically test for the expectations mentioned above, in an xfail approach initially, so that we can evaluate and measurably improve cloud-init's idempotency.
Enhancement
Cloud-init's configuration modules are not idempotent. Some modules attempt to be, but most are not idempotent. Some modules cannot be idempotent, because they allow arbitrary code execution.
Instead of idempotent configuration module implementations, cloud-init uses a frequency-based system. Cloud-config modules run at a frequency of
PER_INSTANCE,PER_BOOT,PER_ONCE, orPER_ALWAYS. These frequencies are sensible given the lifecycle of cloud-init instances and the non-declarative nature of its configuration.Looking at cloud-init through the lens of configuration management, the user interface and frequency-based argument doesn't make as much sense. An ideal user interface would be declarative, and an ideal implementation would be idempotent, and running the command manually would set cloud-init to the declared state regardless of the starting state, and running a configuration module on one platform versus the next cloud produces the same outcomes given the same input configuration (decouple datasource-specific code from platform-specific magic).
Since using cloud-init as a manual configuration tool outside of first boot is not an uncommon request, and since using cloud-init as a configuration tool has long been possible by some un-intuitive and not-well documented (or tested!!!) commands, I propose that to raise the bar initially by creating a set of generic idempotency tests by which we can measure, and therefore improve, the state of cloud-init as a manual configuration tool.
These tests aught to generically test for the expectations mentioned above, in an xfail approach initially, so that we can evaluate and measurably improve cloud-init's idempotency.