Update xDS docs to clarify ordering (#206)

Signed-off-by: Shriram Rajagopalan <shriram@us.ibm.com>

.travis.yml

@@ -1,16 +0,0 @@
-language: minimal
-sudo: required
-services:
-  - docker
-install:
-  - gem install travis --no-rdoc --no-ri
-matrix:
-  fast_finish: true
-env:
-  - TEST_TYPE=bazel.test
-  - TEST_TYPE=bazel.docs
-script: ./ci/ci_steps.sh
-
-branches:
-  only:
-    - master

XDS_PROTOCOL.md

@@ -191,11 +191,23 @@ drop can't be tolerated, traffic drop could have been avoided by providing a
 CDS/EDS update with both __X__ and __Y__, then the RDS update repointing from
 __X__ to __Y__ and then a CDS/EDS update dropping __X__.
 
-In general, to avoid traffic drop:
-* Sequencing should be make before break.
-* LDS and CDS updates should arrive before the respective RDS and EDS updates.
-* CDS/EDS resources corresponding to routes in LDS/RDS should be available at
-  update.
+In general, to avoid traffic drop, sequencing of updates should follow a
+`make before break` model, wherein
+* CDS updates (if any) must always be pushed first.
+* EDS updates (if any) must arrive after CDS updates for the respective clusters.
+* LDS updates must arrive after corresponding CDS/EDS updates.
+* RDS updates related to the newly added listeners must arrive in the end.
+* Stale CDS clusters and related EDS endpoints (ones no longer being
+  referenced) can then be removed.
+
+xDS updates can be pushed independently if no new clusters/routes/listeners
+are added or if it's acceptable to temporarily drop traffic during
+updates. Note that in case of LDS updates, the listeners will be warmed
+before they receive traffic, i.e. the dependent routes are fetched through
+RDS if configured. On the other hand, clusters are not warmed when
+adding/removing/updating clusters. Similarly, routes are not warmed --
+i.e., the management plane must ensure that clusters referenced by a route
+are in place, before pushing the updates for a rotue.
 
 ### Aggregated Discovery Services (ADS)
 

ci/build_setup.sh

@@ -9,11 +9,7 @@ NUM_CPUS=`grep -c ^processor /proc/cpuinfo`
 export ENVOY_SRCDIR=/source
 
 export BUILD_DIR=/build
-if [[ ! -d "${BUILD_DIR}" ]]
-then
-  echo "${BUILD_DIR} mount missing - did you forget -v <something>:${BUILD_DIR}?"
-  exit 1
-fi
+mkdir -p ${BUILD_DIR}
 
 # Create a fake home. Python site libs tries to do getpwuid(3) if we don't and
 # the CI Docker image gets confused as it has no passwd entry when running

ci/ci_steps.sh

@@ -1,17 +0,0 @@
-#!/bin/bash
-
-# Script that lists all the steps take by the CI system when doing Envoy builds.
-set -e
-
-# We reuse the https://github.com/lyft/envoy/ CI image here to get Bazel.
-ENVOY_BUILD_SHA=114e24c6fd05fc026492e9d2ca5608694e5ea59d
-
-# Lint travis file.
-travis lint .travis.yml --skip-completion-check
-
-# Where the Envoy build takes place.
-export ENVOY_API_BUILD_DIR=/tmp/envoy-api-docker-build
-
-# Do a build matrix with different types of builds docs, coverage, bazel.release, etc.
-docker run -t -i -v "$ENVOY_API_BUILD_DIR":/build -v $TRAVIS_BUILD_DIR:/source \
-  lyft/envoy-build:$ENVOY_BUILD_SHA /bin/bash -c "cd /source && ci/do_ci.sh $TEST_TYPE"

ci/run_envoy_docker.sh

@@ -1,11 +0,0 @@
-#!/bin/bash
-
-set -e
-
-[[ -z "${IMAGE_ID}" ]] && IMAGE_ID="latest"
-[[ -z "${ENVOY_API_DOCKER_BUILD_DIR}" ]] && ENVOY_API_DOCKER_BUILD_DIR=/tmp/envoy-api-docker-build
-
-mkdir -p "${ENVOY_API_DOCKER_BUILD_DIR}"
-docker pull lyft/envoy-build:"${IMAGE_ID}"
-docker run -t -i -u $(id -u):$(id -g) -v "${ENVOY_API_DOCKER_BUILD_DIR}":/build \
-  -v "$PWD":/source lyft/envoy-build:"${IMAGE_ID}" /bin/bash -c "cd source && $*"