refactor(roles): remove redundant post-task service and package assertions
Eliminate post-verification discovery and assert tasks (service_facts and package_facts) across all 19 roles and align AGENTS.md. Ansible's built-in declarative modules (package, service) already enforce target state natively and abort execution immediately on failure. The subsequent assertion loops were redundant, added significant runtime overhead, and produced false positives on non-service systemd units (.socket, .timer) and service aliases (e.g., dbus.socket failing under service_facts). - Remove service_facts and Assert Managed Services Are Active across 11 service roles (ensure_apache, ensure_cockpit, ensure_dbus, ensure_dovecot, ensure_fail2ban, ensure_firewalld, ensure_gitea, ensure_mariadb, ensure_podman, ensure_postfix, ensure_timezone). - Remove package_facts and Assert Managed Packages Are Installed across 8 package roles (ensure_ansible_prereq, ensure_git, ensure_os_patch, ensure_os_upgrade, ensure_repo_epel, ensure_repo_rpmfusion, ensure_rsync, ensure_vim). - Update AGENTS.md Section 8.2, Section 10, and Section 21 to codify declarative state enforcement and prohibit redundant post-task assertion loops.
This commit is contained in:
@@ -129,7 +129,6 @@
|
||||
3. **Installation**: Install or remove packages, binaries, and repositories with cryptographic verification.
|
||||
4. **Configuration**: Apply configuration files, drop-in directories, and permissions (least privilege).
|
||||
5. **Service Management**: Enable, start, or manage daemon state and register notifications/handlers.
|
||||
6. **Post-Validation / Health Verification**: Execute end-state verification to prove correct operational state.
|
||||
3. **Platform Data Resolution Hierarchy**:
|
||||
- Platform-specific variables MUST reside in `vars/` and follow a deterministic naming schema based on OS Vendor, OS Major Version, and Architecture (e.g., `vars/{{ ansible_distribution }}_{{ ansible_distribution_major_version }}_{{ ansible_architecture }}.yml`).
|
||||
- Tasks MUST NOT embed OS-specific branching logic (`when: ansible_os_family == '...'`) for package names, service names, or configuration paths.
|
||||
@@ -161,22 +160,14 @@
|
||||
2. **Actionable Diagnostic Requirement**:
|
||||
- All validation failures (static or runtime) MUST produce clear, structured diagnostics stating: the failed constraint, observed vs. expected value, and the explicit remediation step.
|
||||
|
||||
## 10. Deployment Lifecycle, Health Gateways & Rollback Resilience
|
||||
## 10. Deployment Lifecycle, Declarative State & Resilience
|
||||
|
||||
1. **Pre-Change Health & Baseline Validation**:
|
||||
- Prior to applying any configuration, infrastructure, or code change, the execution sequence MUST validate that the target environment and dependent services are in a healthy, operational baseline state.
|
||||
- Pre-change checks MUST be adapted to the specific component being deployed (e.g., verifying database connectivity, checking existing daemon health, validating DNS/network routing, verifying available disk/memory thresholds).
|
||||
- If the pre-change health state fails, deployment MUST halt immediately before mutating any state.
|
||||
2. **Post-Change Operational & Functional Verification**:
|
||||
- Deployment sequences MUST NOT consider a change successful merely because an installer or configuration module exited with status code zero.
|
||||
- Every deployment MUST execute active functional verification against the resulting state:
|
||||
- The process/service is active and enabled.
|
||||
- Sockets and network endpoints are listening and accepting connections.
|
||||
- Application-level synthetic transaction succeeds (e.g., for a web service: HTTP 200 OK with expected payload content, zero 5xx/4xx error pages; for a database: successful query execution).
|
||||
- If post-change verification fails, execution MUST fail fast with detailed operational telemetry.
|
||||
3. **Reversibility & Non-Destructive Failure**:
|
||||
1. **Declarative State Enforcement vs. Redundant Assertions**:
|
||||
- Configuration management modules in Ansible (`ansible.builtin.package`, `ansible.builtin.service`, `ansible.builtin.template`, etc.) are natively declarative and self-enforcing: they enforce the desired target state and halt execution immediately upon encountering an error.
|
||||
- Roles MUST NOT append redundant post-task discovery and assertion loops (e.g., calling `service_facts` or `package_facts` to assert that services are running or packages are installed). Such assertions add execution overhead, do not prevent pre-existing failures ("broken before"), and produce false-positive failures on systemd sockets (`.socket`), timers (`.timer`), and service aliases.
|
||||
2. **Reversibility & Non-Destructive Failure**:
|
||||
- Deployments MUST be engineered to be non-destructive to prior working states.
|
||||
- If a new deployment fails during application or post-verification, the system MUST not leave services in a degraded or corrupted state; atomic rollback strategies, staged deployments, or transaction-safe backups MUST be implemented to preserve or restore the last-known-good operational state.
|
||||
- If a new deployment fails during application, the system MUST not leave services in a degraded or corrupted state; atomic rollback strategies, staged deployments, or transaction-safe backups MUST be implemented to preserve or restore the last-known-good operational state.
|
||||
|
||||
## 11. Infrastructure as Code (Terraform / OpenTofu) Technical Architecture
|
||||
|
||||
@@ -241,7 +232,7 @@
|
||||
- **Dual-Credential Rollover Pattern (Two-Phase Commit)**: When persistent credentials (e.g. static database users, API tokens, SSH keys) are rotated, automation MUST NOT perform single-step destructive overwrites. Rotation MUST follow a Two-Phase commit:
|
||||
1. Stage and create the new credential alongside the existing active credential.
|
||||
2. Update consumer service configuration and reload.
|
||||
3. Execute post-change synthetic verification (Section 10.2).
|
||||
3. Execute synthetic health verification against the service.
|
||||
4. If verification passes, revoke/drop the legacy credential; if verification fails, roll back configuration to the legacy credential and fail fast.
|
||||
- **Idempotent Reconciliation**: Automated periodic runs (e.g. hourly fleet drift runs) MUST NOT generate new credentials unless a rotation trigger or TTL expiration has occurred, ensuring repeated runs remain idempotent with zero unnecessary service reloads.
|
||||
|
||||
@@ -371,7 +362,6 @@ Before finalizing or committing any playbook, role, script, or infrastructure co
|
||||
- [ ] **Security Hardening Enforced**: Non-root daemon users configured, systemd sandboxing parameters enabled, least-privilege permissions applied, and SELinux contexts declared.
|
||||
- [ ] **Zero Credential Leaks**: All tasks and variables handling secrets or certificates enforce `no_log: true` (Ansible) or `sensitive = true` (Terraform/OpenTofu).
|
||||
- [ ] **Idempotency & Least Change**: Tasks modify only the minimal delta from factory defaults; repeated runs against compliant nodes report `changed=0`.
|
||||
- [ ] **Post-Change Verification Active (Section 10.2)**: End-state functional assertions (listening sockets, synthetic HTTP 200 checks, database queries) are implemented.
|
||||
- [ ] **Supply Chain & Licensing Verified**: All third-party packages comply with Tier 1 Libre Open Source licensing (zero BSL/SSPL) with cryptographic SHA-256 validation.
|
||||
- [ ] **Formatting & Accessibility Compliant (`STYLE.md`)**: Narrow-line formatting applied, Yoda/defensive syntax used, attributes lexicographically sorted, and no decorative ASCII art.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user