We have two physically separated management servers for two separate computer clusters (all systems run CentOS 8) and both management servers running xcat. One is a test environment (call test
) and the other is the production (call prod
) environment. They are ALMOST identical, but there are some important file system related differences that must be maintained between the management servers.
We first test a new system change in test
, check that nothing is broken, and then roll it out to prod
. There is a directory, /install/
, on both management servers that contains the xcat
configuration files. When a change is made in /install/
, we copy those changes to another directory (on the same management server), called /backup_install
.
On both management servers (i.e. test
and prod
), /backup_install
is version controlled with git
.
So a typical change might go like :
- Change a configuration file in
/install
on thetest
management server - Roll the change out to the
test
cluster - Check the integrity of the
test
cluster - If its OK, copy changes on
test
management server from/install
to/backup_install
- Commit the changes in
/backup_install
withgit
rsync
the changes in/install
fromtest
management server to/install
onprod
management server- Copy changes on
prod
management server from/install
to/backup_install
- Commit the changes in
/backup_install
onprod
with git
Frequently, users forget to commit changes in /backup_install
on one of the management servers.
One thought I had was to put /install
under version control, instead of /backup_install
. However, xcat
/ confluent
, use those directories directly and I'm mildly paranoid about putting unexpected things (e.g. .git
) in directories used by tools that I don't fully understand.
Question : We are clumsily maintaining two separate git repos on very similar systems on two different management servers. Is there a more efficient, less error prone way of doing this?