Refactor gitlab_consul cookbook for downstream dependencies
The way the gitlab_consul
cookbook is currently written, it assumes that ALL configuration related to consul will be done via that cookbook, and causes issues if another cookbook in the run list attempts to express a dependency on the consul
cookbook to leverage resources for defining/registering services. This issue aims to correct this by
- Refactor the agent and cluster server recipes in
gitlab_consul
to a single, common denominator base for installing consul - Determination of whether an installation is master-eligible should be based on a corresponding attribute rather than which recipe is included in a run list (e.g. set a role attribute, include
gitlab_consul::default
) - Validate proper dependency resolution for defining downstream service dependencies in service-specific cookbooks with a dependency on
gitlab_consul
andinclude_recipe 'gitlab_consul::default'
statements to ensure the agent is installed/available before service registration