Role based service enable/disable
One of the steps in GitLab Server HA: #2452 (closed)
Goal
Make configuring HA servers using GitLab Omnibus easier. Make developing new HA features less prone to introducing regressions in configuration of other services.
Why
Our current role-based implementation for Redis and Geo has resulted in some technical debt and regressions that should be improved while we move forward on our HA configuration. Example of issue here: #2219 (closed)
Our current approach also didn't lend itself to being an obvious choice for managing other services. For example, instead of using roles, we used the prometheus_monitoring['enable']
flag for disabling all the exports. Introducing a separate way of disabling services.
We want to add more roles, to simplify configuring HA GitLab, to try to make it easy to disable unnecessary services while at the same time enabling our current and upcoming HA featureset.
Current Approach
We have 23 services you can set to enable or disable in omnibus. Additionally we have a handful of roles, redis_sentinel, redis_master, redis_slave, geo_primary, geo_secondary
which you can enable. In the case of the redis roles, these forcibly disable gitlab-rails related services, and enforce the redis service to be turned on. In order to disable the gitlab-rails services, it lists and disables each one.
Proposal
This proposal is WIP, and I intend to do small iterations to move towards it. I expect we will change the proposal as each iteration gets us closer to our goal.
-
Role based service enablement by default, rather than service based
- All services default to off unless you have turned them on, or a role has defaulted them on
- The default all-in-one role defaults to on, and includes all our default enabled services that match our current release
- The default all-in-one role turns off the moment you enable another role, unless you explicitly list it as on
- Defaulting services themselves to off separate from a role allows our roles to be additive when configuring
- our current roles mostly disables services, this makes them not very flexible. For example, we don't let you run any non-redis service on any of the redis roles, and we don't provide a way for you to even force one of them on. This was intended to make the configuration easier, but it also made it too rigid.
-
Roles will be defined in code, rather than a simple object hash. (Currently they are in code as well) This allows us to continue to add individual logic to each role easily. For example, the logic preventing redis_slave and redis_master to be enabled on the same node.
-
Services are enabled/disabled using a Services object. This object includes the list of every service we have, and each service will be represented as a object hash, that contains additional information like 'groups'
- Groups will make it somewhat easier to add new services without having to check through the roles. Having a
default
group for example that the default role simply enables all that are in it. - enable/disable methods take exceptions, see proposal here: #2255 (closed)
- Groups will make it somewhat easier to add new services without having to check through the roles. Having a