Added clarification of cloud interaction

keps/sig-cluster-lifecycle/0031-20181022-etcdadm.md

@@ -38,6 +38,7 @@ status: provisional
     * [User Stories](#user-stories)
       * [Manual Cluster Creation](#manual-cluster-creation)
       * [Automatic Cluster Creation](#automatic-cluster-creation)
+      * [Automatic Cluster Creation with EBS volumes](#automatic-cluster-creation-with-ebs-volumes)
     * [Implementation Details/Notes/Constraints](#implementation-detailsnotesconstraints)
     * [Risks and Mitigations](#risks-and-mitigations)
 * [Graduation Criteria](#graduation-criteria)
@@ -78,13 +79,32 @@ We will implement this functionality both as a base layer of imperative (manual
 CLI) operation, and a self-management layer which should enable automated
 in "safe" scenarios (with fallback to manual operation).
 
+We'll also optionally support limited interaction with cloud infrastructure, for
+example for mounting volumes and peer-discovery.  This is primarily for the
+self-management layer, but we'll expose it via etcdadm for consistency and for
+power-users.  The tasks are limited today to listing & mounting a persistent
+volume, and listing instances to find peers.  A full solution for management of
+machines or networks (for example) is out of scope, though we might share some
+example configurations for exposition.  We expect kubernetes installation
+tooling to configure the majority of the cloud infrastructure here, because both
+the configurations and the configuration tooling varies widely.
+
+The big reason that volume mounting is in scope is that volume mounting acts as
+a simple mutex on most clouds - it is a cheap way to boost the safety of our
+leader/gossip algorithms, because we have an external source of truth.
+
+We'll also support reading & writing backups to S3 / GCS etc.
+
 ### Non-Goals
 
 * The project is not targeted at operation of an etcd cluster for use other than
   by Kubernetes apiserver.  We are not building a general-purpose etcd operation
   toolkit.  Likely it will work well for other use-cases, but other tools may be
   more suitable.
-
+* As described above, we aren't building a full "turn up an etcd cluster on a
+  cloud solution"; we expect this to be a building block for use by kubernetes
+  installation tooling (e.g. cluster API solutions).
+
 ## Proposal
 
 We will combine the [etcdadm](https://github.com/platform9/etcdadm) from
@@ -146,6 +166,17 @@ The basic flow would look like:
 peers also running etcdadm, gossips with them to do basic leader election.  When
 sufficient nodes are available to form a quorum, it starts etcd.
 
+#### Automatic Cluster Creation with EBS volumes
+
+etcdadm can also automatically mount EBS volumes.  The workflow looks like this:
+
+* As before, write a configuration file using `etcadm seed ...`, but this time
+  passing additional arguments "--volume-tag cluster=mycluster"
+* Create EBS volumes with the matching tags
+* On each master machine, run `etcdadm auto ...` as before.  Now etcdadm will
+  try to mount a volume with the correct tags before acting as a member of the
+  cluster.
+
 ### Implementation Details/Notes/Constraints
 
 * There will be some changes needed to both platform9/etcdadm (e.g. etcd2
@@ -173,6 +204,7 @@ cluster installations.
 * Much SIG discussion
 * Initial proposal to SIG 2018-10-09
 * Initial KEP draft 2018-10-22 
+* Added clarification of cloud interaction 2018-10-23
 
 ## Infrastructure Needed