This isn't a big deal or blocker for us but I wanted to provide some general sysadmin feedback for you to consider when and if you ever do a major re-work of the product.

CS.cfg currently stores what I would call configuration data and running data. This makes managing the file using configuration management a difficult thing to do. See https://docs.puppetlabs.com/guides/templating.html. A general workflow is a job would run to build out a config file on a regular basis and if we had changed it, bounce the service. So if we wanted to change how apache is configured we'd add or change some stuff in the config mgmt template which can include variable lookup and the machine would automatically pick up and enact those changes. Similarly, if somebody logged directly into the machine and edited the apache config their changes would be rolled back to golden copy next time a config management job ran.

What makes RHCS different from most apps when it comes to this stuff is that RHCS updates its own CS.cfg file as things in the environment change -- serial number ranges, replica id range, etc. Config management can't template the file because it couldn't account for this changing data and would end up replacing it with incorrect values.

To get around this we ended up using https://puppetlabs.com/blog/module-of-the-week-puppetlabsstdlib-puppet-labs-standard-library which more of sed/grep/awk type solution than complete file managment solution. This is considered more of a dirty practice than the template route.

Just food for thought.