ColumnStore currently use postConfigure, mcsadmin and other tools to manage the cluster which requires configurations to be pushed to nodes. This makes it difficult make it work with generic VMs and docker since configuration needs to be known in advance.

Instead we should consider a registration system. The registration server will know what servers are currently connected and what their roles are. If a server connects saying "I want to be a PM server" it is given the IPs of all the other PM servers and the rest of the configuration from the server. At restart time it can the module can then say "I was previously PM1" and be registered on the system accordingly. Configuration would be centrally handled via the registration service.

Possible workflow example:

1. Generic docker image started and it calls something like "registerColumnstore <IP of registration server> PM"
2. The docker image connects to the registration server
3. The registration server sends configuration to docker image
4. The docker image stores that configuration and starts ColumnStore. It also stores the IP of the registration server
5. Another docker image is started as a UM or PM, the process happens as above and the details for the new docker server is pushed to the old one via the registration server.
6. Any configuration changes happen on the registration server which pushes the changes to the UMs and PMs.
7. The registration server can monitor nodes and be an arbitrator for the ccolumnstore cluster if we need one.

Tools such as mcsadmin can still exist, but they would communicate via the registration server, either to change configuration or to get configuration to send messages.