-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Several task patterns are copied near-verbatim across multiple roles. The beats role already partially solved this with beat-install.yml, but the same approach hasn't been applied elsewhere. Consolidating these into the shared elasticstack role would reduce ~300 lines of repetition and make maintenance easier.
Package install pattern (~90 lines across 3 roles) — ES, Kibana, and Logstash each inline an identical three-way split: RPM full-stack (with enablerepo), RPM standalone, and Debian. These differ only in package name and notify handler. Beats already extracted this into beat-install.yml. A shared install_elastic_package.yml in the elasticstack role accepting _pkg_name and _pkg_notify would serve all four roles.
restart_and_verify (4 near-identical files, ~120 lines) — restart_and_verify_elasticsearch.yml, _kibana.yml, _logstash.yml, and _beat.yml are structurally identical: restart service, wait for ActiveState == active with retries, rescue with journalctl diagnostics. The beats version is already parameterized with _beat_service_name. A single shared restart_and_verify_service.yml with _service_name and _daemon_reload parameters would replace all four.
Apt cache update (~20 lines) — an identical apt: update_cache: true, cache_valid_time: 600 block appears in all four service role main.yml files. The shared role's packages.yml already runs the same update. Since cache_valid_time: 600 makes these no-ops within the 10-minute window, the per-role copies are unnecessary noise.
External cert content-mode detection (~120 lines) — the content-mode detection, CA chain counting from inline PEM, and awk-based CA extraction appear in ES, Kibana, and Beats security task files as near-identical blocks differing only in variable prefixes and cert directory paths. A shared cert_detect_content_mode.yml accepting service-specific parameters would eliminate the triplication.
Wait-for-port — ES has a reusable wait_for_instance.yml. Kibana inlines ~30 lines doing the same thing in main.yml. Should share one implementation parameterized by service name and port.
Repos role absorption — the repos role's only job is configuring APT/YUM repos. It always runs before every service role, and the shared elasticstack role already owns all repo-related defaults (elasticstack_repo_base_url, elasticstack_repo_key, elasticstack_release, elasticstack_enable_repos). Absorbing repo tasks into the shared role would eliminate a required but undocumented ordering dependency from every playbook. The elasticstack_enable_repos: false escape hatch already exists for users who manage repos externally.