Introduction: Two Sides of the Same Coin
In Idem, exec modules and idempotent states serve distinct but interrelated functions. While exec modules are the workhorses that execute CRUD operations, idempotent states guarantee consistent resource management. But why keep these two separate? What advantages does this design offer? Let's dive into the mechanics and philosophies that underpin this architectural choice.
The Essence of Exec Modules
CRUD Operations Unpacked
Standard CRUD operations are termed as Create, Read, Update, and Delete. However, in Idem, the "Read" operation is referred to as "Get" to align with Python conventions. Idem also adds a "List" operation in addition to the standard CRUD operations to help with enumeration.
Exec modules in Idem focus on the following CRUD operations:
Create: To make a new instance of a resource.
Get: To retrieve the current state of a resource and returns "False" if the resource does not exist.
Update: To modify an existing resource.
Delete: To remove a resource.
List: To enumerate all instances of a resource.
These functions are not idempotent, meaning they execute exactly what you tell them to do without any underlying logic for state management. They can be invoked directly from the command line and serve as the backbone for Idem's idempotent states.
The Ideology of Idempotent States
Idempotent states in Idem ensure that a given operation will produce the same results, whether it's run once or multiple times. Two primary states govern this:
Present: Ensures a resource exists and is in the specified state. Utilizes Create, Get, and Update from exec modules.
Absent: Ensures a resource doesn't exist. Relies on Delete and Get from exec modules.
The Purpose of Describe
"Describe" exists but is not a state; therefore, it can’t be called from SLS files. It’s meant to create valid "Present" states to help you jumpstart infrastructure management with Idem. If you need to enumerate resources in SLS logic, stick to using the resources "list" or "get function.
"Describe" uses "List" and couples it with the present state's signature to create valid present states for all enumerated resources.
Why Keep Them Separate?
Specialization: Exec modules focus on specific CRUD operations, while idempotent states ensure consistent management.
Reusability: Having CRUD operations in separate exec modules allows for high reusability. Exec modules can be shared across states, used in Jinja statements in SLS files, or used for one-off calls.
Universal CLI: Exec modules are available on the "idem exec" cli -- which exposes the individual calls used by states directly to the user. This also provides a standardized method for accessing all idem resources across multiple clouds.
The Magic of AutoState
AutoState is like the matchmaking friend who knows you so well. By adhering to the auto_state contract in exec modules, Idem can automatically create states that intelligently combine CRUD operations. This not only leads to code reusability but also exposes Idem's core functionalities on the CLI.
Conclusion
Idem's architecture, comprising separate but interrelated exec modules and idempotent states, offers a balanced approach to resource management. While exec modules provide granular control through CRUD operations, idempotent states offer the comfort of consistent and reliable outcomes. The auto_state contract serves as a bridge, leveraging the strengths of both to provide an elegant, reusable, and efficient solution for managing resources.
For those interested in diving deeper into AutoState, consult the Idem documentation. Life's full of complications, but managing resources with Idem doesn't have to be one of them.