Change 33350
Fix perforce-sdp-monitoring's Molecule scenario (never actually ran)
While standing up a real Docker/Molecule environment to verify the
SDP structured-logging changes (sdp CL 33340-33349), I ran both roles'
Molecule scenarios end to end. perforce-sdp-install's passed cleanly, but
perforce-sdp-monitoring's had never actually been exercised under the
current tooling (molecule 26.x / ansible-core 2.21) -- four separate
bugs, each one a fix already present in perforce-sdp-install's own
scenario that was never mirrored over to this sibling scenario:
- molecule.yml embedded perforce_user_password (a $6$ crypt hash)
directly, whose '$' characters broke Molecule's own ${VAR}
interpolation of the file. Moved it to a new group_vars/all.yml,
exactly like perforce-sdp-install already does (see that role's own
group_vars/all.yml comment).
- molecule.yml used the removed community.general.yaml stdout callback;
switched to ansible.builtin.default + result_format: yaml.
- meta/main.yml had no galaxy_info.namespace/role_name override, so
ansible-compat computed an invalid FQRN from the hyphenated directory
name (perforce-sdp-monitoring). Added the same override
perforce-sdp-install's meta/main.yml already has.
- prepare.yml lacked the apt-cache-refresh and RedHat NSS/PAM
permissiveness fixups that perforce-sdp-install's prepare.yml has
(this scenario calls that same role right after), and molecule.yml
was missing ansible_user/ansible_become_method/update_perforce,
needed for the same reasons documented in perforce-sdp-install's
molecule.yml.
With all four fixed, both roles' scenarios pass cleanly end to end on
Ubuntu 22.04 and Rocky 9: fresh SDP install, p4d up and configured,
group-limits guardrails, the full SDP functional test harness, and the
monitoring role's probe/cron/p4prometheus checks including a live
p4_healthcheck.sh run against the real server.
While standing up a real Docker/Molecule environment to verify the
SDP structured-logging changes (sdp CL 33340-33349), I ran both roles'
Molecule scenarios end to end. perforce-sdp-install's passed cleanly, but
perforce-sdp-monitoring's had never actually been exercised under the
current tooling (molecule 26.x / ansible-core 2.21) -- four separate
bugs, each one a fix already present in perforce-sdp-install's own
scenario that was never mirrored over to this sibling scenario:
- molecule.yml embedded perforce_user_password (a $6$ crypt hash)
directly, whose '$' characters broke Molecule's own ${VAR}
interpolation of the file. Moved it to a new group_vars/all.yml,
exactly like perforce-sdp-install already does (see that role's own
group_vars/all.yml comment).
- molecule.yml used the removed community.general.yaml stdout callback;
switched to ansible.builtin.default + result_format: yaml.
- meta/main.yml had no galaxy_info.namespace/role_name override, so
ansible-compat computed an invalid FQRN from the hyphenated directory
name (perforce-sdp-monitoring). Added the same override
perforce-sdp-install's meta/main.yml already has.
- prepare.yml lacked the apt-cache-refresh and RedHat NSS/PAM
permissiveness fixups that perforce-sdp-install's prepare.yml has
(this scenario calls that same role right after), and molecule.yml
was missing ansible_user/ansible_become_method/update_perforce,
needed for the same reasons documented in perforce-sdp-install's
molecule.yml.
With all four fixed, both roles' scenarios pass cleanly end to end on
Ubuntu 22.04 and Rocky 9: fresh SDP install, p4d up and configured,
group-limits guardrails, the full SDP functional test harness, and the
monitoring role's probe/cron/p4prometheus checks including a live
p4_healthcheck.sh run against the real server.