Decouple `repmgr` and `patroni` from `postgres_role`
We currently have a postgres
role that assumes either repmgr or patroni will always be used.
We have this code in http://gitlab.com/gitlab-org/omnibus-gitlab/blob/21b8be3f6175ea1849cfdf336feecde0e1bea562/files/gitlab-cookbooks/package/libraries/config/roles/postgres.rb#L17-25 :
module PostgresRole
def self.load_role
return unless Gitlab['postgres_role']['enable']
Gitlab['repmgr']['enable'] = true if !Gitlab['patroni']['enable'] && Gitlab['repmgr']['enable'].nil?
Services.enable_group('postgres_role')
end
end
This makes it hard to bootstrap a greenfield installation using patroni under certain conditions. On my test cluster, I've opted to run consul server on the same nodes as patroni. In order to solve some racing conditions based on current ansible tasks state, I need to configure the node with patroni configured but disabled, so I get consul up, then I can join the main rails node as part of the patroni cluster, in order to import existing data, and after that enable the other 3 patroni nodes.
Because of this logic here, with patroni disabled, we are bootstrapping repmgr, which is not what I want.
We should consider splitting "HA" logic from this role which originally could be used as a single node postgresql instance.
By removing this line:
Gitlab['repmgr']['enable'] = true if !Gitlab['patroni']['enable'] && Gitlab['repmgr']['enable'].nil?
we force the user to specify whether they want repmgr or patroni enabled, and we don't assume it's repmgr otherwise.