Merge pull request #208 from bacongobbler/beta3

chore(src): bump documentation to reference v2.0.0-beta3

Author: Matthew Fisher

src/installing-workflow/configuring-object-storage.md

@@ -17,15 +17,15 @@ The helm chart for Deis Workflow can be easily configured to connect Workflow co
     * Note: Depending on your chosen object storage you may need to provide globally unique bucket names.
     * Note: If you provide credentials with sufficient access to the underlying storage, Workflow components will create the buckets if they do not exist.
 * **Step 2:** If applicable, generate credentials that have write access to the storage buckets created in Step 1
-* **Step 3:** If you haven't already fetched the helm chart, do so with `helm fetch deis/workflow-beta2`
-* **Step 4:** Open the helm chart with `helm edit workflow-beta2` and look for the template file `tpl/generate_params.toml`
+* **Step 3:** If you haven't already fetched the helm chart, do so with `helm fetch deis/workflow-beta3`
+* **Step 4:** Open the helm chart with `helm edit workflow-beta3` and look for the template file `tpl/generate_params.toml`
 * **Step 5:** Update the `storage` parameter to reference the storage platform you are using: `s3`, `azure`, `gcs`
 * **Step 6:** Update the values in the section which corresponds to your storage type, including region, bucket names and access credentials
     * Note: you do not need to base64 encode any of these values as Helm will handle encoding automatically
-* **Step 7:** Save your changes and re-generate the helm chart by running `helm generate -x manifests workflow-beta2`
+* **Step 7:** Save your changes and re-generate the helm chart by running `helm generate -x manifests workflow-beta3`
 * **Step 8:** Check the generated file in your manifests directory, you should see `deis-objectstorage-secret.yaml`
 
-You are now ready to `helm install workflow-beta2` using your desired object storage.
+You are now ready to `helm install workflow-beta3` using your desired object storage.
 
 ## Object Storage Configuration and Credentials
 

src/installing-workflow/installing-deis-workflow.md

@@ -50,10 +50,10 @@ $ helm repo add deis https://github.com/deis/charts
 Now that you have Helm installed and have added the Deis Chart Repository, install Workflow by running:
 
 ```
-$ helm fetch deis/workflow-beta2             # fetches the chart into a
+$ helm fetch deis/workflow-beta3             # fetches the chart into a
                                              # local workspace
-$ helm generate -x manifests workflow-beta2  # generates various secrets
-$ helm install workflow-beta2                # injects resources into
+$ helm generate -x manifests workflow-beta3  # generates various secrets
+$ helm install workflow-beta3                # injects resources into
                                              # your cluster
 ```
 

src/managing-workflow/platform-logging.md

@@ -10,7 +10,7 @@ The logging platform is made up of 2 components - [Fluentd](https://github.com/d
 Logger acts like a syslog server and receives all log messages that are occurring on the cluster. It then filters this data to only Deis deploy applications and stores those log messages in a ring buffer where they can be fetched via the Deis CLI.
 
 ## Installation
-With the release of workflow-beta2 chart the logging system is part of the main installation of Workflow. You will then need to watch the components come up and verify they are in a running state by executing the following command:
+With the release of workflow-beta3 chart the logging system is part of the main installation of Workflow. You will then need to watch the components come up and verify they are in a running state by executing the following command:
 
 ```
 $ kubectl get pods --namespace=deis
@@ -52,22 +52,22 @@ Error: There are currently no log messages. Please check the following things:
 
 ## Architecture Diagram
 ```
-┌──────────────┐                            
-│              │                            
-│     Host     ├─────┐                      
-│       Fluentd│     │                      
-└──────────────┘   UDP                      
-                     │                      
+┌──────────────┐
+│              │
+│     Host     ├─────┐
+│       Fluentd│     │
+└──────────────┘   UDP
+                     │
 ┌──────────────┐     │      ┌──────────────┐
 │              │     │      │ Logger       │
 │     Host     │─UDP─┼─────▶│     Host     │
 │       Fluentd│     │      │ Fluentd      │
 └──────────────┘     │      └──────────────┘
-┌──────────────┐     │                      
-│              │   UDP                      
-│     Host     │─────┘                      
-│       Fluentd│                            
-└──────────────┘                            
+┌──────────────┐     │
+│              │   UDP
+│     Host     │─────┘
+│       Fluentd│
+└──────────────┘
 ```
 
 ## Default Configuration

src/managing-workflow/upgrading-workflow.md

@@ -3,9 +3,9 @@
 To upgrade to a newer version of Workflow, run the following:
 
 ```
-$ helm uninstall workflow-beta1 -n deis
+$ helm uninstall workflow-beta2 -n deis
 $ helm update
-$ helm fetch deis/workflow-beta2
-$ helm generate -x manifests workflow-beta2
-$ helm install workflow-beta2
+$ helm fetch deis/workflow-beta3
+$ helm generate -x manifests workflow-beta3
+$ helm install workflow-beta3
 ```

src/roadmap/release-checklist.md

@@ -7,8 +7,8 @@ The below sections present a step by step guide to releasing a new Deis Workflow
 examples, we'll be assuming that the below two environment variables are present in wherever
 you're working. Make sure to set them (e.g. by `export`ing them) before you get started.
 
-- `$DEIS_RELEASE` - the full name of this version. For example, `v2.0.0-beta2`
-- `$DEIS_RELEASE_SHORT` - The short name of this version. For example, `beta2`
+- `$DEIS_RELEASE` - the full name of this version. For example, `v2.0.0-beta3`
+- `$DEIS_RELEASE_SHORT` - The short name of this version. For example, `beta3`
 
 # What's a release?
 
@@ -31,8 +31,8 @@ A release consists of the following artifacts:
   - [workflow-manager](https://github.com/deis/workflow-manager)
   - [workflow-cli](https://github.com/deis/workflow-cli)
 2. A new [Helm chart for Deis](https://github.com/deis/charts) that references all of the new
-images referenced above. For example, if `$DEIS_RELEASE` is `2.0.0-beta2`, the new chart would
-be in a new directory called `workflow-beta2`.
+images referenced above. For example, if `$DEIS_RELEASE` is `2.0.0-beta3`, the new chart would
+be in a new directory called `workflow-beta3`.
 
 # Step 1: Get the status of all components
 
@@ -60,21 +60,21 @@ Next, we'll create a new [Helm](https://github.com/helm/helm) chart so that we c
 version of our release for testing. The process is fairly simple:
 
 1. Create a new branch: `git checkout -b release-$DEIS_RELEASE`
-2. Copy an existing chart: `cp -r workflow-beta2 workflow-$DEIS_RELEASE_SHORT`
+2. Copy an existing chart: `cp -r workflow-beta3 workflow-$DEIS_RELEASE_SHORT`
 3. Modify the `workflow-$DEIS_RELEASE_SHORT/tpl/generate_params.toml` file to ensure that all
 `dockerTag` values look like `git-$COMPONENT_SHA_SHORT`, where `$COMPONENT_SHA_SHORT` is the first
 7 characters of the applicable SHA that you got in the previous step.
 4. Ensure that all `DEBUG` variables in manifests are `false`.
 5. Commit your changes: `git commit -a -m "chore(workflow-$DEIS_RELEASE_SHORT): releasing workflow-$DEIS_RELEASE_SHORT"`
 6. Push your changes to your fork: `git push -u $YOUR_FORK_REMOTE release-$DEIS_RELEASE`. Note that
 `$YOUR_FORK_REMOTE` is the git URI to the remote of your `deis/charts` fork. Mine is `git@github.com:arschles/deis-charts.git`, for example.
-7. Do steps 2-5 with the `workflow-beta2-e2e` directory
+7. Do steps 2-5 with the `workflow-beta3-e2e` directory
 8. Open a pull request from your branch to merge into `master` on https://github.com/deis/charts
 
 # Step 3: Manual Testing
 
 After the chart is created with the immutable Docker image tags that represent the final images
-(i.e. the ones that will be re-tagged to the immutable release tag, such as `2.0.0-beta2`), it
+(i.e. the ones that will be re-tagged to the immutable release tag, such as `2.0.0-beta3`), it
 should be manually tested by as many people as possible. Special attention should be paid to the
 user experience, both from an operator and developer perspective.