Documentation: Wrote small stubs for individual components

docs/components/HA-cluster/Governor.md

@@ -0,0 +1,4 @@
+Introduction
+============
+Governor is the process that "governs" PostgreSQL. It uses information from PostgreSQL to determine its health. It uses etcd to determine what role this PostgreSQL instance has within the HA-cluster.
+It can start, restart, promote, rebuild a PostgreSQL instance.

docs/components/HA-cluster/HAProxy.md

@@ -0,0 +1,3 @@
+Introduction
+============
+We use HA-Proxy to route traffic to the right PostgreSQL instance. It uses etcd to determine which ip-address to route the requests to.

docs/components/HA-cluster/etcd-proxy.md

@@ -0,0 +1,3 @@
+Introduction
+============
+The etcd-proxy is the bridge between a HA-Cluster member and the etcd-cluster. By using a etcd-proxy we do not unnecessarily increase the quorum or the write performance of an etcd cluster, but we do have an etcd interface which knows about the etcd-cluster.

docs/components/etcd/dns-sync.md

@@ -0,0 +1,4 @@
+Introduction
+============
+To enable other tools to quickly discover and connect to the etcd-cluster we will update a DNS SRV record that points to the etcd-members.
+We need some sort of process to update this record if it is outdated.

docs/components/etcd/etcd.md

@@ -0,0 +1,9 @@
+Introduction
+============
+For creating an etcd-cluster you need something to discover other members: a (public) etcd server, a valid DNS SRV record, or a static list of other members.
+This is needed to solve the chicken-egg problem: Before the cluster is functional, how do I know about the other cluster members.
+
+To help in solving this issue, we do not start etcd directly; we use a python script that forks an etcd process, after it has established what its peers are.
+It uses immutage AWS tags to gather this information.
+
+The script also takes caring of adding members later on and cleaning up members.