Cert renewal is gated in each role with when: ... or X_cert_will_expire_soon | bool. The flag itself lives in roles/<role>/vars/main.yml (and roles/elasticstack/vars/main.yml for the CA one), set to false. The cert_check_expiry task flips it to true when the cert is close to its not_valid_after, and that path works correctly.
The catch is that setting these flags from outside the role doesn't work the way you'd expect. Role vars from vars/main.yml have higher precedence than play vars, so if a playbook does vars: elasticstack_ca_will_expire_soon: true and then includes the role, the role re-imports its own vars/main.yml and reverts the value to false. Renewal never fires.
I hit this writing the cert_renewal scenario's renewal play in PR #155. The workaround is to set *_cert_expiration_buffer: 99999 instead, which IS overridable (it's a default), and lets the cert_check_expiry task do the actual flipping. That works, but it's a non-obvious indirection — the variable named ..._will_expire_soon is the one you'd reach for, and setting it appears to do nothing.
Two ways to close this. Move the flags from vars/main.yml to defaults/main.yml so they behave like every other tunable, or document the _expiration_buffer workaround prominently in the renewal docs. The first is cleaner if the flag was never meant to be private state; the second is fine if it was.
Cert renewal is gated in each role with
when: ... or X_cert_will_expire_soon | bool. The flag itself lives inroles/<role>/vars/main.yml(androles/elasticstack/vars/main.ymlfor the CA one), set tofalse. The cert_check_expiry task flips it to true when the cert is close to itsnot_valid_after, and that path works correctly.The catch is that setting these flags from outside the role doesn't work the way you'd expect. Role vars from
vars/main.ymlhave higher precedence than play vars, so if a playbook doesvars: elasticstack_ca_will_expire_soon: trueand then includes the role, the role re-imports its ownvars/main.ymland reverts the value tofalse. Renewal never fires.I hit this writing the cert_renewal scenario's renewal play in PR #155. The workaround is to set
*_cert_expiration_buffer: 99999instead, which IS overridable (it's a default), and lets the cert_check_expiry task do the actual flipping. That works, but it's a non-obvious indirection — the variable named..._will_expire_soonis the one you'd reach for, and setting it appears to do nothing.Two ways to close this. Move the flags from
vars/main.ymltodefaults/main.ymlso they behave like every other tunable, or document the_expiration_bufferworkaround prominently in the renewal docs. The first is cleaner if the flag was never meant to be private state; the second is fine if it was.