Update README.md

diff --git a/README.md b/README.md
index 01a9462365ba4c09e2f0507cb1b9ad30fc9773d8..87eaae0a3ab3708f5fd7cd07fc05d3fcd02e7f61 100644 (file)
--- a/README.md
+++ b/README.md
@@ -442,6 +442,22 @@ entweder `test` oder `live`.
 **Achtung**: Durch die Limitierung von Terraform darf es in einem Terraform-Projekt nur ein VSphere geben,
 damit macht es Sinn, diesen Parameter nur ein einziges Mal anzugeben, nämlich im obersten Template.
 
+##### cluster
+
+Hier wird das VSphere-Rechencluster festgelegt. Welches Cluster man festlegt, hängt davon ab,
+in Welchem **vsphere** die VMs provisioniert werden sollen.
+
+Im **live** VSPhere stehen folgende Cluster zur Verfügung:
+
+* vmcc-l015-01 (Alle ESX-Hosts mit Intel-CPU)
+* vmcc-l015-02 (Alle ESX-Hosts mit amd-cpu)
+
+Im **test** VSPhere stehen folgende Cluster zur Verfügung:
+
+* test-vmcc-105-02
+* test-vmcc-l105-01
+* vmcc-l65-01
+
 ##### vm\_folder
 
 Der Name des Ordners innerhalb des Baums der 'VMs und Vorlagen'-Ansicht in VSPhere. Dabei achtet
@@ -619,6 +635,85 @@ Falls diese Vorlage (unwahrscheinlicherweise, aber man weiß ja nie) kaputt und
 verwendungsfähig ist, kann man sich auch in VSPhere unter _'VMs und Vorlagen'_ im Ordner
 **templates** eine der rotierten Vorlagen aussuchen.
 
+##### puppet
+
+Das ist ein Hash, dessen Key-Value-Paare zur Einrichtung des Puppet-Agents dienen.
+
+Mit allen Angabes sieht das ungefähr so aus:
+
+    puppet:
+      contact: dba@pixelpark.com
+      customer: pixelpark
+      environment: development
+      project: postgresql-dev
+      role: dpx-postgresql::cluster_node
+      tier: development
+
+###### puppet/contact
+
+Das ist von den Angaben die unwichtigste. Es ist ein einfacher Free-Form-String
+(Mindestlänge 1 Zeichen), der lediglich für die Generierung der `/etc/motd` zum Anzeigen
+der Mailadresse des zuständigen Kontaktes beim Login auf dem Host verwendet wird.
+
+Vorgabewert: _8x5@pixelpark.com_
+
+###### puppet/customer
+
+Das zeigt den Kundennamen in Puppet-Hiera an, also den Verzeichnisnamen in Hiera unterhalb
+von `customers`, unterhalb dessen die zuständigen YAML-Dateien für den Host
+gefunden werden.
+
+Dieses ist eine **obligatorische** Angabe.
+
+###### puppet/environment
+
+Das beschreibt das **r10k Environment**, das für diese VM zuständig sein soll.
+Damit werden also alle Puppet-Module und deren Versionen benannt, die für die Konfiguration
+des Hosts verwendet werden können.
+
+Dieses ist eine **obligatorische** Angabe.
+
+Vorgabewert: _development_
+
+###### puppet/project
+
+Dieser **optionale** Wert beschreibt das Kundenprojekt in Hiera, also ein Unterverzeichnis
+in Hiera unterhalb des Kundenverzeinisses, unterhalb dessen die zuständigen YAML-Dateien
+für den Host gefunden werden.
+
+Für das obige Beispiel wäre das also in Hiera das Verzeichnis `customer/pixelpark/postgresql-dev`.
+
+Wenn wes weggelassen (die Vorgabe) oder ausdrücklich auf '**~**' gesetzt wird, dann kann nur
+diremt im Kundenverzeichnis im Hiera nach den zuständigen YAML-Dateien gesucht werden.
+
+###### puppet/role
+
+Das beschreibt die eindeutige Rolle aus dem Puppet-Modul **pixelpark-infra**, die dem Host
+zugewiesen wird.
+
+Dieses ist eine **obligatorische** Angabe.
+
+**Achtung**: Diese Rolle **muss** mit der Angabe `infra::role` in der zuständigen Host-YAML
+übereinstimmen. Deshalb ist es am günstigsten, die entsprechenden Strukturen und Dateien
+im Hiera _vor_ der Provisionierung anzulegen.
+
+Vorgabewert: _default_
+
+###### puppet/tier
+
+Die logische Einordung der VM in den Entwicklungs-Stand des Kunden. Das stimmt nicht
+zwangsweise mit dem Puppet-Environment überein.
+
+Mögliche Werte:
+
+* development
+* test
+* production
+
+Praktisch verbirgt sich dahinter, dass beim Durchsuchen des Hiera auch gleichnamige
+YAML-Dateien unterhalb des Kunden-Projekt-Ordners und des Kunden-Ordners mit
+herangezogen werden.
+
 ## 3. FeatureRequests
 
 ### 3.1 change vSphere Host per need in terraform yaml (live <--> test)