Add ha roles

[LongLiveCHIEF]

This pull request adds the roles configuration item for controlling scaled instances of GitLab Omnibus.

[eputnam]

some overlooked whitespace and a few rubocop offenses to review

[eputnam]

:(

[LongLiveCHIEF]

Will fix.

[eputnam]

is there a way to make this var name more descriptive? perhaps $ha_roles or something like that?

[LongLiveCHIEF]

For the most part, this module uses variables that are consistent with the names of the config keys expected by the product. This allows users to reference the product documentation for how a config is expected to change the behavior of the product, and removes ambiguity/uncertainty by the implementor on whether or not our name for a config is really some other config for the gitlab.rb.template, which is what this module configures.

[eputnam]

docs! \o/

[LongLiveCHIEF]

see my comment above. The standard for this module is to document something that is not a feature of the omnibus package configuration. Documenting every config would be redundant, and could cause unexpected problems when gitlab changes the behavior or possible sub-key values.

There fore, the documentation provided for this param is adequate and in keeping with the standards of this module.

[LongLiveCHIEF]

@eputnam are you familiar with the product itself? It seems like some of the review items you raised are indicating that you're unaware that this module is basically puppetizing a chef configuration, and that we're merely automating the generation of that config file according to the docs maintained by the vendor.

We can't be the source of documentation for these configs, because it creates too many issues when debugging configuration problems. When we automate some manual part of the omnibus package/service, then we document it... otherwise we merely indicate an expected type for each param, and in the param docs we point to the usage of that config by the vendor.

It's confusing unless you're familiar with how GitLab Omnibus is administered.

Discussion concerns are within standards and are consistent with user expectations for implementing this module.

[LongLiveCHIEF]

@eputnam a good example of how we document non gitlab.rb.template features is actually present in one of my other open Merge Requests: Db indexing for git authorized keys.

This is a feature of GitLab that requires manual configuration by the installer, (whereas the majority are handled by the bundled chef process according to the settings realized in gitlab.rb). As such, I added a section to the README.md about enabling it in the module, in addition to the param docs.

Make sense? Sound good? Maybe we should actually document this distinction in the README so that module consumers don't have to figure out implicitly how our documentation works?