An interface that can be reviewed
A reusable role needs to state what it accepts, which values are allowed and which effects it produces. In the original lab, role_port defaults to 8080 and its interface requires an integer among 7070, 8080 and 9090. The body only writes a temporary file; it opens no network port. This contract supports input review before the main task. For a middleware role, also document each parameter’s meaning, unit and compatibility. A valid integer may still be inappropriate for a particular application or change.
Trace the effective value to its source
Three controlled runs produce 8080 from the default, 9090 from an inventory variable and 7070 from JSON extra vars. The result teaches precedence in the observed context, not a rule based on the last line in a file. The lab also defines policy_label in the play and role vars: role-policy prevails. For a value consumers should configure easily, defaults is a different choice from vars. During change review, record effective sources, including inventory and pipeline inputs, without including secrets in the report.
Validate inputs without assuming a transaction
The invalid-port input is rejected by role validation and the body’s file is not created. That observation bounds this role’s execution. It does not prove that no earlier step changed the environment. Documentation also describes dependency validation before the role depending on it. In a fictional pipeline, earlier preparation may already have created directories. Before rerunning, identify tasks actually executed and existing effects. An interface failure indicates an unmet contract; it is neither a global rollback nor automatic approval to clean up.
Dynamic exposure and confidentiality
With include_role and public=false, default exposure_value exists inside the role but not in the following task. With public=true, the earlier observation remains false and the following one becomes true. This exposure applies to subsequent tasks after dynamic inclusion; it does not recompute tasks already executed. The setting also does not automatically protect content emitted through debug. To review confidentiality, use fictional markers and trace their path into logs and artifacts. Treat variable availability and information protection as separate requirements with their own controls and appropriate output access.
Role compatibility and acceptance
A new role version may accept the same type while changing a parameter’s meaning. Review the contract, dependencies and consumers before updating the pipeline reference. Argument validation is only one layer. A role producing configuration still needs evidence that the candidate is suitable, publication reached the correct target and the process uses the intended generation. The lab executes no real service, so the resulting file only establishes value selection and writing with this local executor. Those limits belong alongside the recorded result when reviewing operational readiness.
Port approval workshop
In the fictional case, the change approves 8080 and the firewall permits only that port. An override selects 7070, which belongs to the role’s valid choices. Hold application and align the effective value with the approved decision, or obtain a scope change with reviewed dependencies. Prepare evidence containing role version, variable sources and resulting value. Communicate: “The input passes role validation, but it differs from the approved port.” This wording separates technical behavior from the outstanding decision without claiming a service outage that has not been observed.
Role default: 8080; inventory: 9090; extra vars: 7070. All three results were written to temporary files by ansible-core 2.21.4 without application connections.
Common pitfalls
Confusing choices with authorization; using vars for all configuration; assuming public protects logs; interpreting failed validation as reversal of earlier tasks.
Related topics: Tasks and desired state · Batch orchestration · Failures and recovery
A reviewable interface needs value origins, explicit limits and outcome criteria. Passing role validation establishes neither activation nor operational approval.
Reference: Reusing Ansible artifacts: roles · Ansible community 14 / ansible-core 2.21 documentation consulted 2026-09-30; executor, collection and plugin compatibility requires confirmation