Move k8s-bootstrap container to blueprints repo1.9.0

Cleanup of unnecessary input templates and other files
Use non-templatized blueprints instead of blueprint templates
Copy blueprints from blueprints/ directory into image
Move reference_templates to top-level directory

Issue-ID: DCAEGEN2-2041
Signed-off-by: Jack Lucas <jflucas@research.att.com>
Change-Id: Ib846a96a4995eb97383f63ff764705e6277a24b0

1 files changed, 36 insertions, 0 deletions

diff --git a/README.md b/README.md
new file mode 100644
index 0000000..8d3a870
--- /dev/null
+++ b/README.md
@@ -0,0 +1,36 @@
+# DCAE Blueprints and Bootstrap Container
+This repository holds the source code needed to build the
+Docker image for the DCAE bootstrap container.  The bootstrap
+container runs at DCAE deployment time (via a Helm chart) and
+does initial setup of the DCAE environment.  This includes
+deploying several service components using Cloudify Manager.
+
+This repository also holds Cloudify blueprints for service components.
+The Docker build process copies these blueprints into the Docker image
+for the bootstrap container.
+
+_Note: Prior to the Frankfurt release (R6), this repository held blueprint templates
+for components deployed using Cloudify Manager.   The build process for this
+repository expanded the templates and pushed them to the Nexus raw
+repository.  The DCAE bootstrap container was hosted in the `dcaegen2.deployments` repository.  The Docker build process for the bootstrap containter image pulled the blueprints it needed from the Nexus raw repository._
+
+## DCAE Bootstrap Container
+This container is responsible for loading plugins and wagons onto the
+DCAE Cloudify Manager instance and for launching DCAE components.
+
+The Docker image build process loads plugins and blueprints into the
+image's file system.  The plugins are pulled from the Nexus raw repository.  The
+blueprints are copied from the `blueprints` directory in this repository.  At run time, the main script in the container
+(`bootstrap.sh`) uploads the plugins to Cloudify Manager, then installs
+components using the blueprints.
+
+The container expects to be started with two environment variables:
+  - `CMADDR` -- the address of the target Cloudify Manager
+  - `CMPASS` -- the password for Cloudify Manager
+
+The container expects input files to use when deploying the blueprints.
+It expects to find them in /inputs.   The normal method for launching
+the container is via a Helm Chart launched by OOM.  That chart creates
+a Kubernetes ConfigMap containing the input files.  The ConfigMap is
+mounted as a volume at /inputs.
+