Description: The current behavior of the Ansible Automation Platform (AAP) installer involves re-pushing deployment files to all application nodes every time the setup script is executed, irrespective of whether any configuration changes have been made. This approach contradicts the core principle of idempotency, which is fundamental to Ansible's design – actions should only be performed if they are truly necessary to achieve the desired state.

This feature requests that the AAP installer be updated to incorporate checks before pushing deployment files to application nodes. These checks should determine if files have changed or if the target state has already been achieved. Only if differences are detected should the installer proceed with pushing files and applying changes.

Business Justification:

• Improved Deployment Efficiency: Eliminating unnecessary file transfers and configuration applications will significantly reduce the time required for installer runs, especially in large-scale deployments or during iterative development and testing cycles. This translates to faster deployments and quicker recovery times.
• Enhanced Deployment Consistency and Reliability: An idempotent installer reduces the risk of unintended side effects or inconsistencies that can arise from re-applying identical configurations. It ensures that the system only changes when explicitly required, leading to more predictable and reliable deployments.
• Reduced Resource Consumption: Avoiding superfluous file pushes and configuration steps will decrease network traffic and CPU/disk utilization on both the control node and the application nodes, optimizing resource usage.
• Alignment with Ansible Best Practices: Bringing the AAP installer in line with Ansible's core principle of idempotency reinforces best practices and provides a more consistent user experience for those familiar with Ansible's design philosophy. This also improves the overall perception of AAP as a robust automation solution.
• Facilitates Automation of Installer Runs: For organizations that automate or script their AAP installations and updates, an idempotent installer provides greater stability and allows for more robust automation workflows, as repeated execution will not lead to unnecessary operations.

Technical Considerations:

• File Hashing/Checksums: The installer could employ file hashing (e.g., MD5, SHA256) on the source deployment files and compare them to hashes of existing files on the target nodes. If hashes match, the file doesn't need to be re-pushed.
• Configuration State Comparison: For configuration parameters, the installer would need a mechanism to read the current state on the target node and compare it to the desired state defined in the deployment files. This might involve parsing configuration files or querying APIs.
• Ansible copy module checksum parameter: The ansible.builtin.copy module already supports the checksum parameter for idempotent file transfers. The installer's underlying Ansible playbooks should leverage this feature where appropriate.
• Conditional Logic in Playbooks: The installer's internal Ansible playbooks would need to be refactored to incorporate conditional logic (e.g., when clauses, changed_when directives) to skip tasks if no changes are detected.
• Detection of Service State: Beyond just file content, the installer might need to check the status of services or other runtime configurations to determine if a restart or re-application is truly necessary.
• Impact on Upgrade Paths: Careful consideration must be given to how idempotency affects upgrades. The installer needs to differentiate between a fresh installation/re-run and an upgrade where some components are expected to change.
• Rollback Implications: While idempotency improves stability, any changes made should still be considered for rollback strategies if a failure occurs during a necessary update.
• Performance Overhead of Checks: The overhead of performing these pre-push checks must be minimal so as not to negate the performance benefits of idempotency. Hashing large files or complex state comparisons should be optimized.
• Logging and Reporting: The installer should clearly log when tasks are skipped due to idempotency, providing transparency and aiding in troubleshooting.

Acceptance Criteria:

• Executing the setup script multiple times without any changes to the installer's configuration files results in no file transfers to application nodes and no changes reported for most tasks.
• Only tasks directly related to configuration changes are executed when modifications are made to the installer's input.
• Deployment times for subsequent runs of the installer (without changes) are significantly reduced compared to the current behavior.