From bf830cc4dd5653adf53b75afa48ab1e79c4da575 Mon Sep 17 00:00:00 2001
From: Abhinav Dahiya <abhinav.dahiya@redhat.com>
Date: Wed, 11 Jul 2018 14:40:30 -0700
Subject: [PATCH] Documentation/design: add prepare design

---
 Documentation/design/preparephase.md | 93 ++++++++++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 Documentation/design/preparephase.md

diff --git a/Documentation/design/preparephase.md b/Documentation/design/preparephase.md
new file mode 100644
index 00000000000..7a45215ff34
--- /dev/null
+++ b/Documentation/design/preparephase.md
@@ -0,0 +1,93 @@
+# Prepare
+
+## Goal
+
+1. Generation of the final Ignition configurations for the master and bootstrap nodes.
+
+2. Prepare needs to validate that the assets required to bootstrap the cluster are present and correct.
+
+## Overview
+
+The prepare step is responsible for taking all of the generated assets, including any user-customizations, and generating the final asset state that will be used by the infrastructure provisioning tool.
+
+This step is necessary because when a user modifies assets after the `render` phase - we must consume them into the final cluster states that will be applied at installation.
+
+In most cases, prepare should only be responsible for generating a bootstrap node ignition config, a master node ignition stub, and provisioning tool specific files (e.g. tfvars). All other asset generation should be the result of the `render` step
+
+## Detailed Design
+
+### Idempotency
+
+Prepare should be able to be run multiple times, with the output simply replacing any previously generated state. This is to allow a user to modify their source assets, and easily re-generate the configuration that will be used by the installer.
+
+### Validation
+
+Prepare should validate that assets required for bootstrap are present. For example,
+
+1. etcd-cert-signer-server on bootstrap node.
+2. machineconfig server on bootstrap node.
+3. bootkube service for bootstrap node.
+4. kubelet service file for bootstrap node. and maybe more..
+
+### Extra assets added by user
+
+The user can customize the assets generated by `render` step. The user can also add new assets that need to be installed in the cluster. Prepare step should allow addition of assets by user.
+
+The type of additions that are allowed are:
+
+1. Assets like systemd-service files for bootstrap node.
+2. Kubernetes objects to be installed in the cluster.
+
+The type of additions not supported are:
+
+1. Assets like systemd-service files for master and worker nodes.
+
+For example,
+
+If the directory before running prepare looks like:
+
+```
+./install-config.yaml
+./auth/kubeconfig-admin
+./auth/kubeconfig-bootstrap
+./manifests/kube-core-operator.yaml
+./manifests/kube-core-config.yaml
+./manifests/kube-core-operator-sa.yaml
+./manifests/network-operator.yaml
+./manifests/network-config.yaml
+./manifests/network-operator-sa.yaml
+...
+./tls/root-ca.crt
+./tls/root-ca.key
+./tls/kube-ca.crt
+./tls/kube-ca.key
+```
+
+The user can edit the `./manifests/network-config.yaml` file to update network related configuration.
+
+### Output
+
+The Prepare step creates ignition file for bootstrap, master and worker node namely, `bootstrap.ign`, `master.ign` and `worker.ign` in the current working directory or the directory specified by `--assets-dir` flag.
+
+The directory after prepare would look like
+
+```
+./install-config.yaml
+./auth/kubeconfig-admin
+./auth/kubeconfig-bootstrap
+./ign/bootstrap.ign
+./ign/master.ign
+./ign/worker.ign
+./manifests/kube-core-operator.yaml
+./manifests/kube-core-config.yaml
+./manifests/kube-core-operator-sa.yaml
+...
+./tls/root-ca.crt
+./tls/root-ca.key
+./tls/kube-ca.crt
+./tls/kube-ca.key
+```
+
+#### TODO
+
+1. The prepare might have to create some `tf files` for launching the cluster with terraform.
\ No newline at end of file